Re: [RFC] net: phy: read link status twice when phy_check_link_status()

[liuyonglong]

On 2019/7/31 13:44, Heiner Kallweit wrote:
> On 31.07.2019 05:33, liuyonglong wrote:
>>
>>
>> On 2019/7/31 3:04, Heiner Kallweit wrote:
>>> On 30.07.2019 08:35, liuyonglong wrote:
 :/sys/kernel/debug/tracing$ cat trace
 # tracer: nop
 #
 # entries-in-buffer/entries-written: 45/45   #P:128
 #
 #  _-=> irqs-off
 # / _=> need-resched
 #| / _---=> hardirq/softirq
 #|| / _--=> preempt-depth
 #||| / delay
 #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
 #  | |   |      | |
 kworker/64:2-1028  [064]    172.295687: mdio_access: 
 mii-:bd:00.0 read  phy:0x01 reg:0x02 val:0x001c
 kworker/64:2-1028  [064]    172.295726: mdio_access: 
 mii-:bd:00.0 read  phy:0x01 reg:0x03 val:0xc916
 kworker/64:2-1028  [064]    172.296902: mdio_access: 
 mii-:bd:00.0 read  phy:0x01 reg:0x01 val:0x79ad
 kworker/64:2-1028  [064]    172.296938: mdio_access: 
 mii-:bd:00.0 read  phy:0x01 reg:0x0f val:0x2000
 kworker/64:2-1028  [064]    172.321213: mdio_access: 
 mii-:bd:00.0 read  phy:0x01 reg:0x00 val:0x1040
 kworker/64:2-1028  [064]    172.343209: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x02 val:0x001c
 kworker/64:2-1028  [064]    172.343245: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x03 val:0xc916
 kworker/64:2-1028  [064]    172.343882: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
 kworker/64:2-1028  [064]    172.343918: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x0f val:0x2000
 kworker/64:2-1028  [064]    172.362658: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
 kworker/64:2-1028  [064]    172.385961: mdio_access: 
 mii-:bd:00.2 read  phy:0x05 reg:0x02 val:0x001c
 kworker/64:2-1028  [064]    172.385996: mdio_access: 
 mii-:bd:00.2 read  phy:0x05 reg:0x03 val:0xc916
 kworker/64:2-1028  [064]    172.386646: mdio_access: 
 mii-:bd:00.2 read  phy:0x05 reg:0x01 val:0x79ad
 kworker/64:2-1028  [064]    172.386681: mdio_access: 
 mii-:bd:00.2 read  phy:0x05 reg:0x0f val:0x2000
 kworker/64:2-1028  [064]    172.411286: mdio_access: 
 mii-:bd:00.2 read  phy:0x05 reg:0x00 val:0x1040
 kworker/64:2-1028  [064]    172.433225: mdio_access: 
 mii-:bd:00.3 read  phy:0x07 reg:0x02 val:0x001c
 kworker/64:2-1028  [064]    172.433260: mdio_access: 
 mii-:bd:00.3 read  phy:0x07 reg:0x03 val:0xc916
 kworker/64:2-1028  [064]    172.433887: mdio_access: 
 mii-:bd:00.3 read  phy:0x07 reg:0x01 val:0x79ad
 kworker/64:2-1028  [064]    172.433922: mdio_access: 
 mii-:bd:00.3 read  phy:0x07 reg:0x0f val:0x2000
 kworker/64:2-1028  [064]    172.452862: mdio_access: 
 mii-:bd:00.3 read  phy:0x07 reg:0x00 val:0x1040
 ifconfig-1324  [011]    177.325585: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
   kworker/u257:0-8 [012]    177.325642: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x04 val:0x01e1
   kworker/u257:0-8 [012]    177.325654: mdio_access: 
 mii-:bd:00.1 write phy:0x03 reg:0x04 val:0x05e1
   kworker/u257:0-8 [012]    177.325708: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
   kworker/u257:0-8 [012]    177.325744: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x09 val:0x0200
   kworker/u257:0-8 [012]    177.325779: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
   kworker/u257:0-8 [012]    177.325788: mdio_access: 
 mii-:bd:00.1 write phy:0x03 reg:0x00 val:0x1240
   kworker/u257:0-8 [012]    177.325843: mdio_access: 
 mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x798d
>>>
>>> What I think that happens here:
>>> Writing 0x1240 to BMCR starts aneg. When reading BMSR immediately after 
>>> that then the PHY seems to have cleared
>>> the "aneg complete" bit already, but not yet the "link up" bit. This 
>>> results in the false "link up" notification.
>>> The following patch is based on the fact that in case of enabled aneg we 
>>> can't have a valid link if aneg isn't
>>> finished. Could you please test whether this works for you?
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index 6b5cb87f3..7ddd91df9 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -1774,6 +1774,12 @@ int genphy_update_link(struct phy_device *phydev)
>>> phydev->link = status & BMSR_LSTATUS ? 1 : 0;
>>> 

Re: [PATCH v4 06/10] modpost: Add modinfo flag to livepatch modules

[Masahiro Yamada]

Hi Joe,


On Thu, May 9, 2019 at 11:39 PM Joe Lawrence  wrote:
>
> From: Miroslav Benes 
>
> Currently, livepatch infrastructure in the kernel relies on
> MODULE_INFO(livepatch, "Y") statement in a livepatch module. Then the
> kernel module loader knows a module is indeed livepatch module and can
> behave accordingly.
>
> klp-convert, on the other hand relies on LIVEPATCH_* statement in the
> module's Makefile for exactly the same reason.
>
> Remove dependency on modinfo and generate MODULE_INFO flag
> automatically in modpost when LIVEPATCH_* is defined in the module's
> Makefile. Generate a list of all built livepatch modules based on
> the .livepatch file and store it in (MODVERDIR)/livepatchmods. Give
> this list as an argument for modpost which will use it to identify
> livepatch modules.
>
> As MODULE_INFO is no longer needed, remove it.


I do not understand this patch.
This makes the implementation so complicated.

I think MODULE_INFO(livepatch, "Y") is cleaner than
LIVEPATCH_* in Makefile.


How about this approach?


[1] Make modpost generate the list of livepatch modules.
(livepatch-modules)

[2] Generate Symbols.list in scripts/Makefile.modpost
(vmlinux + modules excluding livepatch-modules)

[3] Run klp-convert for modules in livepatch-modules.


If you do this, you can remove most of the build system hacks
can't you?


I attached an example implementation for [1].

Please check whether this works.

Thanks.



-- 
Best Regards
Masahiro Yamada
From 85571430aa12cd19a75cbc856da1092199876e6a Mon Sep 17 00:00:00 2001
From: Masahiro Yamada 
Date: Wed, 31 Jul 2019 14:51:29 +0900
Subject: [PATCH] livepatch: make modpost generate the list of livepatch
 modules

Reverse the livepatch-modules direction.

The modpost generates the livepatch-modules file instead of
Makefile feeding it to modpost.

The implementation just mimics write_dump().

Signed-off-by: Masahiro Yamada 
---
 scripts/Makefile.modpost |  3 ++-
 scripts/mod/modpost.c| 28 ++--
 scripts/mod/modpost.h|  1 +
 3 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/scripts/Makefile.modpost b/scripts/Makefile.modpost
index 92ed02d7cd5e..c884b7b709ca 100644
--- a/scripts/Makefile.modpost
+++ b/scripts/Makefile.modpost
@@ -56,7 +56,8 @@ MODPOST = scripts/mod/modpost		\
 	$(if $(KBUILD_EXTMOD),$(addprefix -e ,$(KBUILD_EXTRA_SYMBOLS)))	\
 	$(if $(KBUILD_EXTMOD),-o $(modulesymfile))			\
 	$(if $(CONFIG_SECTION_MISMATCH_WARN_ONLY),,-E)			\
-	$(if $(KBUILD_MODPOST_WARN),-w)
+	$(if $(KBUILD_MODPOST_WARN),-w)	\
+	$(if $(CONFIG_LIVEPATCH),-l livepatch-modules)
 
 ifdef MODPOST_VMLINUX
 
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 3e6d36ddfcdf..e3f637f225e4 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1976,6 +1976,10 @@ static void read_symbols(const char *modname)
 		license = get_next_modinfo(, "license", license);
 	}
 
+	/* Livepatch modules have unresolved symbols resolved by klp-convert */
+	if (get_modinfo(, "livepatch"))
+		mod->livepatch = 1;
+
 	for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
 		symname = remove_dot(info.strtab + sym->st_name);
 
@@ -2118,7 +2122,7 @@ static int check_exports(struct module *mod)
 		const char *basename;
 		exp = find_symbol(s->name);
 		if (!exp || exp->module == mod) {
-			if (have_vmlinux && !s->weak) {
+			if (have_vmlinux && !s->weak && !mod->livepatch) {
 if (warn_unresolved) {
 	warn("\"%s\" [%s.ko] undefined!\n",
 	 s->name, mod->name);
@@ -2429,6 +2433,20 @@ static void write_dump(const char *fname)
 	free(buf.p);
 }
 
+static void write_livepatch_modules(const char *fname)
+{
+	struct buffer buf = { };
+	struct module *mod;
+
+	for (mod = modules; mod; mod = mod->next) {
+		if (mod->livepatch)
+			buf_printf(, "%s\n", mod->name);
+	}
+
+	write_if_changed(, fname);
+	free(buf.p);
+}
+
 struct ext_sym_list {
 	struct ext_sym_list *next;
 	const char *file;
@@ -2440,13 +2458,14 @@ int main(int argc, char **argv)
 	struct buffer buf = { };
 	char *kernel_read = NULL, *module_read = NULL;
 	char *dump_write = NULL, *files_source = NULL;
+	char *livepatch_modules = NULL;
 	int opt;
 	int err;
 	int n;
 	struct ext_sym_list *extsym_iter;
 	struct ext_sym_list *extsym_start = NULL;
 
-	while ((opt = getopt(argc, argv, "i:I:e:mnsT:o:awE")) != -1) {
+	while ((opt = getopt(argc, argv, "i:I:e:l:mnsT:o:awE")) != -1) {
 		switch (opt) {
 		case 'i':
 			kernel_read = optarg;
@@ -2463,6 +2482,9 @@ int main(int argc, char **argv)
 			extsym_iter->file = optarg;
 			extsym_start = extsym_iter;
 			break;
+		case 'l':
+			livepatch_modules = optarg;
+			break;
 		case 'm':
 			modversions = 1;
 			break;
@@ -2535,6 +2557,8 @@ int main(int argc, char **argv)
 	}
 	if (dump_write)
 		write_dump(dump_write);
+	if (livepatch_modules)
+		write_livepatch_modules(livepatch_modules);
 	if (sec_mismatch_count && sec_mismatch_fatal)
 		fatal("modpost: Section mismatches detected.\n"
 		  "Set 

[PATCHv9 3/3] arm64: dts: qcom: msm8996: Add Coresight support

[Sai Prakash Ranjan]

From: Vivek Gautam 

Enable coresight support by adding device nodes for the
available source, sinks and channel blocks on msm8996.

This also adds coresight cpu debug nodes.

Signed-off-by: Vivek Gautam 
Signed-off-by: Sai Prakash Ranjan 
Reviewed-by: Mathieu Poirier 
Acked-by: Suzuki K Poulose 
---
 arch/arm64/boot/dts/qcom/msm8996.dtsi | 468 ++
 1 file changed, 468 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi 
b/arch/arm64/boot/dts/qcom/msm8996.dtsi
index 96c0a481f454..1533df63f056 100644
--- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
@@ -633,6 +633,474 @@
reg = <0x30 0x9>;
};
 
+   stm@3002000 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0x3002000 0x1000>,
+ <0x828 0x18>;
+   reg-names = "stm-base", "stm-stimulus-base";
+
+   clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   out-ports {
+   port {
+   stm_out: endpoint {
+   remote-endpoint =
+ <_in>;
+   };
+   };
+   };
+   };
+
+   tpiu@302 {
+   compatible = "arm,coresight-tpiu", "arm,primecell";
+   reg = <0x302 0x1000>;
+
+   clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   in-ports {
+   port {
+   tpiu_in: endpoint {
+   remote-endpoint =
+ <_out1>;
+   };
+   };
+   };
+   };
+
+   funnel@3021000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x3021000 0x1000>;
+
+   clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@7 {
+   reg = <7>;
+   funnel0_in: endpoint {
+   remote-endpoint =
+ <_out>;
+   };
+   };
+   };
+
+   out-ports {
+   port {
+   funnel0_out: endpoint {
+   remote-endpoint =
+ <_funnel_in0>;
+   };
+   };
+   };
+   };
+
+   funnel@3022000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x3022000 0x1000>;
+
+   clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@6 {
+   reg = <6>;
+   funnel1_in: endpoint {
+   remote-endpoint =
+ <_merge_funnel_out>;
+   };
+   };
+   };
+
+   out-ports {
+   port {
+   funnel1_out: endpoint {
+   remote-endpoint =
+ <_funnel_in1>;
+   };
+   };
+   };
+   };
+
+   funnel@3023000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x3023000 0x1000>;
+
+   clocks = < RPM_QDSS_CLK>, < RPM_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+
+   out-ports {
+

[PATCHv9 0/3] Add coresight support for SDM845, MSM8998 and MSM8996

[Sai Prakash Ranjan]

This patch series adds support for coresight on SDM845, MSM8998, and MSM8996.

* Patch 1 adds device tree nodes for SDM845 coresight components.

* Patch 2 adds device tree nodes for MSM8998 coresight components.

* Patch 3 adds device tree nodes for MSM8996 coresight components.

All the previous dependencies are now merged.

This patch series has been tested on SDM845 MTP and MSM8996
based Dragonboard 820c and MSM8998 MTP.

Test results for SDM845 and MSM8996 with scatter gather are uploaded to below 
github link:
 - https://github.com/saiprakash-ranjan/coresight-test-results 

v9:
 * Add test results for SDM845 and MSM8996.
 * Add missing funnel node in MSM8996.
 
v8:
 * Change to clocks instead of power domain for SDM845.
 * Fix compilation with uci_id_debug struct changed to const.
 * Rebase on top of linux-next.

v7:
 * Change uci_id_debug struct to const.
 * Update the subject as suggested by Suzuki.

v6:
 * Update the UCI table with the new macro introduced by
   Mike.
 * Rebase on top of coresight-next and provide a tree with
   all the dependent patches applied.

v5:
 * Added coresight support for MSM8998.
 * Added ETM PIDs for SDM845 and MSM8996 as suggested
   by Suzuki.
 * Added UCI table for Coresight CPU debug module.

v4:
 * Mask out the minor version as suggested by Mathieu.
 * Added the dependent patch description in patch 1.

v3:
 * Added arm,scatter-gather property as suggested by Suzuki.

v2:
 * Added coresight support for msm8996 based on Vivek's patch.
   Cleaned up and added coresight cpu debug nodes for msm8996.
 * Merged coresight dtsi file into sdm845.dtsi as suggested by Bjorn
 * Addressed Mathieu's feedback about masking the minor version in
   etm4_arch_supported() and added a comment for reason to bypass
   the AMBA bus discovery method.

Sai Prakash Ranjan (2):
  arm64: dts: qcom: sdm845: Add Coresight support
  arm64: dts: qcom: msm8998: Add Coresight support

Vivek Gautam (1):
  arm64: dts: qcom: msm8996: Add Coresight support

 arch/arm64/boot/dts/qcom/msm8996.dtsi | 468 ++
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 435 
 arch/arm64/boot/dts/qcom/sdm845.dtsi  | 451 +
 3 files changed, 1354 insertions(+)

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation

[PATCHv9 1/3] arm64: dts: qcom: sdm845: Add Coresight support

[Sai Prakash Ranjan]

Add coresight components found on Qualcomm SDM845 SoC.

Signed-off-by: Sai Prakash Ranjan 
Reviewed-by: Mathieu Poirier 
Acked-by: Suzuki K Poulose 
---
 arch/arm64/boot/dts/qcom/sdm845.dtsi | 451 +++
 1 file changed, 451 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 4babff5f19b5..82c990196796 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1815,6 +1815,457 @@
clock-names = "xo";
};
 
+   stm@6002000 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0 0x06002000 0 0x1000>,
+ <0 0x1628 0 0x18>;
+   reg-names = "stm-base", "stm-stimulus-base";
+
+   clocks = <_qmp>;
+   clock-names = "apb_pclk";
+
+   out-ports {
+   port {
+   stm_out: endpoint {
+   remote-endpoint =
+ <_in7>;
+   };
+   };
+   };
+   };
+
+   funnel@6041000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0 0x06041000 0 0x1000>;
+
+   clocks = <_qmp>;
+   clock-names = "apb_pclk";
+
+   out-ports {
+   port {
+   funnel0_out: endpoint {
+   remote-endpoint =
+ <_funnel_in0>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@7 {
+   reg = <7>;
+   funnel0_in7: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
+   funnel@6043000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0 0x06043000 0 0x1000>;
+
+   clocks = <_qmp>;
+   clock-names = "apb_pclk";
+
+   out-ports {
+   port {
+   funnel2_out: endpoint {
+   remote-endpoint =
+ <_funnel_in2>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@5 {
+   reg = <5>;
+   funnel2_in5: endpoint {
+   remote-endpoint =
+ <_merge_funnel_out>;
+   };
+   };
+   };
+   };
+
+   funnel@6045000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0 0x06045000 0 0x1000>;
+
+   clocks = <_qmp>;
+   clock-names = "apb_pclk";
+
+   out-ports {
+   port {
+   merge_funnel_out: endpoint {
+   remote-endpoint = <_in>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   merge_funnel_in0: endpoint {
+   remote-endpoint =
+ <_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+   merge_funnel_in2: endpoint {
+   

[PATCHv9 2/3] arm64: dts: qcom: msm8998: Add Coresight support

[Sai Prakash Ranjan]

Enable coresight support by adding device nodes for the
available source, sinks and channel blocks on MSM8998.

Signed-off-by: Sai Prakash Ranjan 
Reviewed-by: Mathieu Poirier 
Acked-by: Suzuki K Poulose 
---
 arch/arm64/boot/dts/qcom/msm8998.dtsi | 435 ++
 1 file changed, 435 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi 
b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index c13ed7aeb1e0..ad661fcc9e1b 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -822,6 +822,441 @@
#interrupt-cells = <0x2>;
};
 
+   stm@6002000 {
+   compatible = "arm,coresight-stm", "arm,primecell";
+   reg = <0x06002000 0x1000>,
+ <0x1628 0x18>;
+   reg-names = "stm-base", "stm-data-base";
+
+   clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   out-ports {
+   port {
+   stm_out: endpoint {
+   remote-endpoint = 
<_in7>;
+   };
+   };
+   };
+   };
+
+   funnel@6041000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x06041000 0x1000>;
+
+   clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   out-ports {
+   port {
+   funnel0_out: endpoint {
+   remote-endpoint =
+ <_funnel_in0>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@7 {
+   reg = <7>;
+   funnel0_in7: endpoint {
+   remote-endpoint = <_out>;
+   };
+   };
+   };
+   };
+
+   funnel@6042000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x06042000 0x1000>;
+
+   clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   out-ports {
+   port {
+   funnel1_out: endpoint {
+   remote-endpoint =
+ <_funnel_in1>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@6 {
+   reg = <6>;
+   funnel1_in6: endpoint {
+   remote-endpoint =
+ <_merge_funnel_out>;
+   };
+   };
+   };
+   };
+
+   funnel@6045000 {
+   compatible = "arm,coresight-dynamic-funnel", 
"arm,primecell";
+   reg = <0x06045000 0x1000>;
+
+   clocks = < RPM_SMD_QDSS_CLK>, < 
RPM_SMD_QDSS_A_CLK>;
+   clock-names = "apb_pclk", "atclk";
+
+   out-ports {
+   port {
+   merge_funnel_out: endpoint {
+   remote-endpoint =
+ <_in>;
+   };
+   };
+   };
+
+   in-ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   merge_funnel_in0: endpoint {
+   remote-endpoint =
+ <_out>;
+   };
+

Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S

[Tao Ren]

On 7/30/19 7:34 PM, Andrew Lunn wrote:
>> Hi Andrew,
>>
>> The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over 
>> backplane (1000Base-KX).
> 
> Ah, that is different. So the board is using it for RGMII to 1000Base-KX?
> 
> phy-mode is about the MAC-PHY link. So in this case RGMII.

Yes. It's RGMII to 1000Base-KX.

> There is no DT way to configure the PHY-Switch link. However, it
> sounds like you have the PHY strapped so it is doing 1000BaseX on the
> PHY-Switch link. So do you actually need to configure this?

The PHY is strapped in RGMII-Fiber Mode (the term used in datasheet), but 
besides 1000BaseX, 100Base-FX is also supported in this mode.
The datasheet doesn't say which link type (1000BaseX or 100Base-FX) is active 
after reset and I cannot find a way to auto-detect the link type, either.

Below are a few more details about 1000Base-X and 100Base-FX in BCM54616S 
datasheet.

- 1000BaseX: 
  The 1000BaseX register set (MII registers 00-0F) needs to be enabled by 
setting bit 0 of Mode Control Register.
  Although the register address is the same between 1000BaseX and 
1000BaseT/100BaseT/10BaseT registers, some bit fields in 1000BaseX registers 
are different: for example, speed field is not available in 1000BaseX status 
register.

- 100Base-FX:
  100Base-FX registers need to be enabled by writing 1 to SerDes 100FX Control 
Register.
  100Base-FX Control and Status registers are in shadow register 1Ch, instead 
of MII register 00h and 01h.

> You report you never see link up? So maybe the problem is actually in
> read_status? When in 1000BaseX mode, do you need to read the link
> status from some other register? The Marvell PHYs use a second page
> for 1000BaseX.

read_status callback needs to be updated to report correct link speed in my 
case. But as I cannot tell which link type (1000BaseX or 100Base-FX) is active, 
it becomes hard to access registers in read_status method. Any suggestions?

BTW, link-never-up issue seems to be caused by static/dynamic feature 
detection. I'm still tracing down the issue and it's being tracked in patch #1 
of the series.


Thanks,

Tao

Re: [PATCH net-next 1/2] net: phy: broadcom: set features explicitly for BCM54616S

[Heiner Kallweit]

On 31.07.2019 02:12, Tao Ren wrote:
> On 7/29/19 11:00 PM, Heiner Kallweit wrote:
>> On 30.07.2019 07:05, Tao Ren wrote:
>>> On 7/29/19 8:35 PM, Andrew Lunn wrote:
 On Mon, Jul 29, 2019 at 05:25:32PM -0700, Tao Ren wrote:
> BCM54616S feature "PHY_GBIT_FEATURES" was removed by commit dcdecdcfe1fc
> ("net: phy: switch drivers to use dynamic feature detection"). As dynamic
> feature detection doesn't work when BCM54616S is working in RGMII-Fiber
> mode (different sets of MII Control/Status registers being used), let's
> set "PHY_GBIT_FEATURES" for BCM54616S explicitly.

 Hi Tao

 What exactly does it get wrong?

  Thanks
Andrew
>>>
>>> Hi Andrew,
>>>
>>> BCM54616S is set to RGMII-Fiber (1000Base-X) mode on my platform, and none 
>>> of the features (1000BaseT/100BaseT/10BaseT) can be detected by 
>>> genphy_read_abilities(), because the PHY only reports 1000BaseX_Full|Half 
>>> ability in this mode.
>>>
>> Are you going to use the PHY in copper or fibre mode?
>> In case you use fibre mode, why do you need the copper modes set as 
>> supported?
>> Or does the PHY just start in fibre mode and you want to switch it to copper 
>> mode?
> 
> Hi Heiner,
> 
> The phy starts in fiber mode and that's the mode I want.
> My observation is: phydev->link is always 0 (Link status bit is never set in 
> MII_BMSR) by using dynamic ability detection on my machine. I checked 
> phydev->supported and it's set to "AutoNeg | TP | MII | Pause | Asym_Pause" 
> by dynamic ability detection. Is it normal/expected? Or maybe the fix should 
> go to different places? Thank you for your help.
> 

Not sure whether you stated already which kernel version you're using.
There's a brand-new extension to auto-detect 1000BaseX:
f30e33bcdab9 ("net: phy: Add more 1000BaseX support detection")
It's included in the 5.3-rc series.

If a feature can be read from a vendor-specific register only,
then the preferred way is: Implement callback get_features in
the PHY driver, call genphy_read_abilities for the basic features
and complement it with reading the vendor-specific register(s).

> 
> Thanks,
> 
> Tao
> 
Heiner

Re: [RFC] net: phy: read link status twice when phy_check_link_status()

[Heiner Kallweit]

On 31.07.2019 05:33, liuyonglong wrote:
> 
> 
> On 2019/7/31 3:04, Heiner Kallweit wrote:
>> On 30.07.2019 08:35, liuyonglong wrote:
>>> :/sys/kernel/debug/tracing$ cat trace
>>> # tracer: nop
>>> #
>>> # entries-in-buffer/entries-written: 45/45   #P:128
>>> #
>>> #  _-=> irqs-off
>>> # / _=> need-resched
>>> #| / _---=> hardirq/softirq
>>> #|| / _--=> preempt-depth
>>> #||| / delay
>>> #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
>>> #  | |   |      | |
>>> kworker/64:2-1028  [064]    172.295687: mdio_access: 
>>> mii-:bd:00.0 read  phy:0x01 reg:0x02 val:0x001c
>>> kworker/64:2-1028  [064]    172.295726: mdio_access: 
>>> mii-:bd:00.0 read  phy:0x01 reg:0x03 val:0xc916
>>> kworker/64:2-1028  [064]    172.296902: mdio_access: 
>>> mii-:bd:00.0 read  phy:0x01 reg:0x01 val:0x79ad
>>> kworker/64:2-1028  [064]    172.296938: mdio_access: 
>>> mii-:bd:00.0 read  phy:0x01 reg:0x0f val:0x2000
>>> kworker/64:2-1028  [064]    172.321213: mdio_access: 
>>> mii-:bd:00.0 read  phy:0x01 reg:0x00 val:0x1040
>>> kworker/64:2-1028  [064]    172.343209: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x02 val:0x001c
>>> kworker/64:2-1028  [064]    172.343245: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x03 val:0xc916
>>> kworker/64:2-1028  [064]    172.343882: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
>>> kworker/64:2-1028  [064]    172.343918: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x0f val:0x2000
>>> kworker/64:2-1028  [064]    172.362658: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>>> kworker/64:2-1028  [064]    172.385961: mdio_access: 
>>> mii-:bd:00.2 read  phy:0x05 reg:0x02 val:0x001c
>>> kworker/64:2-1028  [064]    172.385996: mdio_access: 
>>> mii-:bd:00.2 read  phy:0x05 reg:0x03 val:0xc916
>>> kworker/64:2-1028  [064]    172.386646: mdio_access: 
>>> mii-:bd:00.2 read  phy:0x05 reg:0x01 val:0x79ad
>>> kworker/64:2-1028  [064]    172.386681: mdio_access: 
>>> mii-:bd:00.2 read  phy:0x05 reg:0x0f val:0x2000
>>> kworker/64:2-1028  [064]    172.411286: mdio_access: 
>>> mii-:bd:00.2 read  phy:0x05 reg:0x00 val:0x1040
>>> kworker/64:2-1028  [064]    172.433225: mdio_access: 
>>> mii-:bd:00.3 read  phy:0x07 reg:0x02 val:0x001c
>>> kworker/64:2-1028  [064]    172.433260: mdio_access: 
>>> mii-:bd:00.3 read  phy:0x07 reg:0x03 val:0xc916
>>> kworker/64:2-1028  [064]    172.433887: mdio_access: 
>>> mii-:bd:00.3 read  phy:0x07 reg:0x01 val:0x79ad
>>> kworker/64:2-1028  [064]    172.433922: mdio_access: 
>>> mii-:bd:00.3 read  phy:0x07 reg:0x0f val:0x2000
>>> kworker/64:2-1028  [064]    172.452862: mdio_access: 
>>> mii-:bd:00.3 read  phy:0x07 reg:0x00 val:0x1040
>>> ifconfig-1324  [011]    177.325585: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>>>   kworker/u257:0-8 [012]    177.325642: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x04 val:0x01e1
>>>   kworker/u257:0-8 [012]    177.325654: mdio_access: 
>>> mii-:bd:00.1 write phy:0x03 reg:0x04 val:0x05e1
>>>   kworker/u257:0-8 [012]    177.325708: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
>>>   kworker/u257:0-8 [012]    177.325744: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x09 val:0x0200
>>>   kworker/u257:0-8 [012]    177.325779: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>>>   kworker/u257:0-8 [012]    177.325788: mdio_access: 
>>> mii-:bd:00.1 write phy:0x03 reg:0x00 val:0x1240
>>>   kworker/u257:0-8 [012]    177.325843: mdio_access: 
>>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x798d
>>
>> What I think that happens here:
>> Writing 0x1240 to BMCR starts aneg. When reading BMSR immediately after that 
>> then the PHY seems to have cleared
>> the "aneg complete" bit already, but not yet the "link up" bit. This results 
>> in the false "link up" notification.
>> The following patch is based on the fact that in case of enabled aneg we 
>> can't have a valid link if aneg isn't
>> finished. Could you please test whether this works for you?
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index 6b5cb87f3..7ddd91df9 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1774,6 +1774,12 @@ int genphy_update_link(struct phy_device *phydev)
>>  phydev->link = status & BMSR_LSTATUS ? 1 : 0;
>>  phydev->autoneg_complete = status & BMSR_ANEGCOMPLETE ? 1 : 0;
>>  
>> +/* Consider the case that autoneg was started and "aneg 

[PATCH v2 0/1] x86/boot: save fields explicitly, zero out everything else

[john . hubbard]

From: John Hubbard 

Hi,

This uses the "save each field explicitly" approach that we discussed
during the first review [1]. As in [1], this is motivated by a desire
to clear the compiler warnings when building with gcc 9.

This is difficult to properly test. I've done a basic boot test, but
if there are actually errors in which items get zeroed or not, I don't
have a good test to uncover that.

[1] 
https://lore.kernel.org/r/alpine.deb.2.21.1907260036500.1...@nanos.tec.linutronix.de

John Hubbard (1):
  x86/boot: save fields explicitly, zero out everything else

 arch/x86/include/asm/bootparam_utils.h | 62 +++---
 1 file changed, 47 insertions(+), 15 deletions(-)

-- 
2.22.0

[PATCH v2] x86/boot: save fields explicitly, zero out everything else

[john . hubbard]

From: John Hubbard 

Recent gcc compilers (gcc 9.1) generate warnings about an
out of bounds memset, if you trying memset across several fields
of a struct. This generated a couple of warnings on x86_64 builds.

Fix this by explicitly saving the fields in struct boot_params
that are intended to be preserved, and zeroing all the rest.

Suggested-by: Thomas Gleixner 
Suggested-by: H. Peter Anvin 
Signed-off-by: John Hubbard 
---
 arch/x86/include/asm/bootparam_utils.h | 62 +++---
 1 file changed, 47 insertions(+), 15 deletions(-)

diff --git a/arch/x86/include/asm/bootparam_utils.h 
b/arch/x86/include/asm/bootparam_utils.h
index 101eb944f13c..514aee24b8de 100644
--- a/arch/x86/include/asm/bootparam_utils.h
+++ b/arch/x86/include/asm/bootparam_utils.h
@@ -18,6 +18,20 @@
  * Note: efi_info is commonly left uninitialized, but that field has a
  * private magic, so it is better to leave it unchanged.
  */
+
+#define sizeof_mbr(type, member) ({ sizeof(((type *)0)->member); })
+
+#define BOOT_PARAM_PRESERVE(struct_member) \
+   {   \
+   .start = offsetof(struct boot_params, struct_member),   \
+   .len   = sizeof_mbr(struct boot_params, struct_member), \
+   }
+
+struct boot_params_to_save {
+   unsigned int start;
+   unsigned int len;
+};
+
 static void sanitize_boot_params(struct boot_params *boot_params)
 {
/* 
@@ -35,21 +49,39 @@ static void sanitize_boot_params(struct boot_params 
*boot_params)
 * problems again.
 */
if (boot_params->sentinel) {
-   /* fields in boot_params are left uninitialized, clear them */
-   boot_params->acpi_rsdp_addr = 0;
-   memset(_params->ext_ramdisk_image, 0,
-  (char *)_params->efi_info -
-   (char *)_params->ext_ramdisk_image);
-   memset(_params->kbd_status, 0,
-  (char *)_params->hdr -
-  (char *)_params->kbd_status);
-   memset(_params->_pad7[0], 0,
-  (char *)_params->edd_mbr_sig_buffer[0] -
-   (char *)_params->_pad7[0]);
-   memset(_params->_pad8[0], 0,
-  (char *)_params->eddbuf[0] -
-   (char *)_params->_pad8[0]);
-   memset(_params->_pad9[0], 0, sizeof(boot_params->_pad9));
+   static struct boot_params scratch;
+   char *bp_base = (char *)boot_params;
+   char *save_base = (char *)
+   int i;
+
+   const struct boot_params_to_save to_save[] = {
+   BOOT_PARAM_PRESERVE(screen_info),
+   BOOT_PARAM_PRESERVE(apm_bios_info),
+   BOOT_PARAM_PRESERVE(tboot_addr),
+   BOOT_PARAM_PRESERVE(ist_info),
+   BOOT_PARAM_PRESERVE(acpi_rsdp_addr),
+   BOOT_PARAM_PRESERVE(hd0_info),
+   BOOT_PARAM_PRESERVE(hd1_info),
+   BOOT_PARAM_PRESERVE(sys_desc_table),
+   BOOT_PARAM_PRESERVE(olpc_ofw_header),
+   BOOT_PARAM_PRESERVE(efi_info),
+   BOOT_PARAM_PRESERVE(alt_mem_k),
+   BOOT_PARAM_PRESERVE(scratch),
+   BOOT_PARAM_PRESERVE(e820_entries),
+   BOOT_PARAM_PRESERVE(eddbuf_entries),
+   BOOT_PARAM_PRESERVE(edd_mbr_sig_buf_entries),
+   BOOT_PARAM_PRESERVE(edd_mbr_sig_buffer),
+   BOOT_PARAM_PRESERVE(e820_table),
+   BOOT_PARAM_PRESERVE(eddbuf),
+   };
+
+   memset(, 0, sizeof(scratch));
+
+   for (i = 0; i < ARRAY_SIZE(to_save); i++)
+   memcpy(save_base + to_save[i].start,
+  bp_base + to_save[i].start, to_save[i].len);
+
+   memcpy(boot_params, save_base, sizeof(*boot_params));
}
 }
 
-- 
2.22.0

Re: [PATCH] mm: release the spinlock on zap_pte_range

[Minchan Kim]

On Tue, Jul 30, 2019 at 02:57:51PM +0200, Michal Hocko wrote:
> [Cc Nick - the email thread starts 
> http://lkml.kernel.org/r/20190729071037.241581-1-minc...@kernel.org
>  A very brief summary is that mark_page_accessed seems to be quite
>  expensive and the question is whether we still need it and why
>  SetPageReferenced cannot be used instead. More below.]
> 
> On Tue 30-07-19 21:39:35, Minchan Kim wrote:
> > On Tue, Jul 30, 2019 at 02:32:37PM +0200, Michal Hocko wrote:
> > > On Tue 30-07-19 21:11:10, Minchan Kim wrote:
> > > > On Mon, Jul 29, 2019 at 10:35:15AM +0200, Michal Hocko wrote:
> > > > > On Mon 29-07-19 17:20:52, Minchan Kim wrote:
> > > > > > On Mon, Jul 29, 2019 at 09:45:23AM +0200, Michal Hocko wrote:
> > > > > > > On Mon 29-07-19 16:10:37, Minchan Kim wrote:
> > > > > > > > In our testing(carmera recording), Miguel and Wei found 
> > > > > > > > unmap_page_range
> > > > > > > > takes above 6ms with preemption disabled easily. When I see 
> > > > > > > > that, the
> > > > > > > > reason is it holds page table spinlock during entire 512 page 
> > > > > > > > operation
> > > > > > > > in a PMD. 6.2ms is never trivial for user experince if RT task 
> > > > > > > > couldn't
> > > > > > > > run in the time because it could make frame drop or glitch 
> > > > > > > > audio problem.
> > > > > > > 
> > > > > > > Where is the time spent during the tear down? 512 pages doesn't 
> > > > > > > sound
> > > > > > > like a lot to tear down. Is it the TLB flushing?
> > > > > > 
> > > > > > Miguel confirmed there is no such big latency without 
> > > > > > mark_page_accessed
> > > > > > in zap_pte_range so I guess it's the contention of LRU lock as well 
> > > > > > as
> > > > > > heavy activate_page overhead which is not trivial, either.
> > > > > 
> > > > > Please give us more details ideally with some numbers.
> > > > 
> > > > I had a time to benchmark it via adding some trace_printk hooks between
> > > > pte_offset_map_lock and pte_unmap_unlock in zap_pte_range. The testing
> > > > device is 2018 premium mobile device.
> > > > 
> > > > I can get 2ms delay rather easily to release 2M(ie, 512 pages) when the
> > > > task runs on little core even though it doesn't have any IPI and LRU
> > > > lock contention. It's already too heavy.
> > > > 
> > > > If I remove activate_page, 35-40% overhead of zap_pte_range is gone
> > > > so most of overhead(about 0.7ms) comes from activate_page via
> > > > mark_page_accessed. Thus, if there are LRU contention, that 0.7ms could
> > > > accumulate up to several ms.
> > > 
> > > Thanks for this information. This is something that should be a part of
> > > the changelog. I am sorry to still poke into this because I still do not
> > 
> > I will include it.
> > 
> > > have a full understanding of what is going on and while I do not object
> > > to drop the spinlock I still suspect this is papering over a deeper
> > > problem.
> > 
> > I couldn't come up with better solution. Feel free to suggest it.
> > 
> > > 
> > > If mark_page_accessed is really expensive then why do we even bother to
> > > do it in the tear down path in the first place? Why don't we simply set
> > > a referenced bit on the page to reflect the young pte bit? I might be
> > > missing something here of course.
> > 
> > commit bf3f3bc5e73
> > Author: Nick Piggin 
> > Date:   Tue Jan 6 14:38:55 2009 -0800
> > 
> > mm: don't mark_page_accessed in fault path
> > 
> > Doing a mark_page_accessed at fault-time, then doing SetPageReferenced 
> > at
> > unmap-time if the pte is young has a number of problems.
> > 
> > mark_page_accessed is supposed to be roughly the equivalent of a young 
> > pte
> > for unmapped references. Unfortunately it doesn't come with any context:
> > after being called, reclaim doesn't know who or why the page was 
> > touched.
> > 
> > So calling mark_page_accessed not only adds extra lru or PG_referenced
> > manipulations for pages that are already going to have pte_young ptes 
> > anyway,
> > but it also adds these references which are difficult to work with from 
> > the
> > context of vma specific references (eg. MADV_SEQUENTIAL pte_young may 
> > not
> > wish to contribute to the page being referenced).
> > 
> > Then, simply doing SetPageReferenced when zapping a pte and finding it 
> > is
> > young, is not a really good solution either. SetPageReferenced does not
> > correctly promote the page to the active list for example. So after 
> > removing
> > mark_page_accessed from the fault path, several mmap()+touch+munmap() 
> > would
> > have a very different result from several read(2) calls for example, 
> > which
> > is not really desirable.
> 
> Well, I have to say that this is rather vague to me. Nick, could you be
> more specific about which workloads do benefit from this change? Let's
> say that the zapped pte is the only referenced one and then reclaim
> finds the page on inactive list. We would go and reclaim 

[PATCH net-next v2 0/4] net: phy: Add AST2600 MDIO support

[Andrew Jeffery]

Hello,

v2 of the ASPEED MDIO series addresses comments from Rob on the devicetree
bindings and Andrew on the driver itself.

v1 of the series can be found here:

http://patchwork.ozlabs.org/cover/1138140/

Please review!

Andrew

Andrew Jeffery (4):
  dt-bindings: net: Add aspeed,ast2600-mdio binding
  net: phy: Add mdio-aspeed
  net: ftgmac100: Add support for DT phy-handle property
  net: ftgmac100: Select ASPEED MDIO driver for the AST2600

 .../bindings/net/aspeed,ast2600-mdio.yaml |  45 +
 drivers/net/ethernet/faraday/Kconfig  |   1 +
 drivers/net/ethernet/faraday/ftgmac100.c  |  37 -
 drivers/net/phy/Kconfig   |  13 ++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/mdio-aspeed.c | 157 ++
 6 files changed, 250 insertions(+), 4 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
 create mode 100644 drivers/net/phy/mdio-aspeed.c

-- 
2.20.1

[PATCH net-next v2 2/4] net: phy: Add mdio-aspeed

[Andrew Jeffery]

The AST2600 design separates the MDIO controllers from the MAC, which is
where they were placed in the AST2400 and AST2500. Further, the register
interface is reworked again, so now we have three possible different
interface implementations, however this driver only supports the
interface provided by the AST2600. The AST2400 and AST2500 will continue
to be supported by the MDIO support embedded in the FTGMAC100 driver.

The hardware supports both C22 and C45 mode, but for the moment only C22
support is implemented.

Signed-off-by: Andrew Jeffery 

---
v2:
* Use readl_poll_timeout() instead of open-coded loop
* Error on C45 accesses
---
 drivers/net/phy/Kconfig   |  13 +++
 drivers/net/phy/Makefile  |   1 +
 drivers/net/phy/mdio-aspeed.c | 157 ++
 3 files changed, 171 insertions(+)
 create mode 100644 drivers/net/phy/mdio-aspeed.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 20f14c5fbb7e..206d8650ee7f 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -21,6 +21,19 @@ config MDIO_BUS
 
 if MDIO_BUS
 
+config MDIO_ASPEED
+   tristate "ASPEED MDIO bus controller"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   depends on OF_MDIO && HAS_IOMEM
+   help
+ This module provides a driver for the independent MDIO bus
+ controllers found in the ASPEED AST2600 SoC. This is a driver for the
+ third revision of the ASPEED MDIO register interface - the first two
+ revisions are the "old" and "new" interfaces found in the AST2400 and
+ AST2500, embedded in the MAC. For legacy reasons, FTGMAC100 driver
+ continues to drive the embedded MDIO controller for the AST2400 and
+ AST2500 SoCs, so say N if AST2600 support is not required.
+
 config MDIO_BCM_IPROC
tristate "Broadcom iProc MDIO bus controller"
depends on ARCH_BCM_IPROC || COMPILE_TEST
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 839acb292c38..ba07c27e4208 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -22,6 +22,7 @@ libphy-$(CONFIG_LED_TRIGGER_PHY)  += phy_led_triggers.o
 obj-$(CONFIG_PHYLINK)  += phylink.o
 obj-$(CONFIG_PHYLIB)   += libphy.o
 
+obj-$(CONFIG_MDIO_ASPEED)  += mdio-aspeed.o
 obj-$(CONFIG_MDIO_BCM_IPROC)   += mdio-bcm-iproc.o
 obj-$(CONFIG_MDIO_BCM_UNIMAC)  += mdio-bcm-unimac.o
 obj-$(CONFIG_MDIO_BITBANG) += mdio-bitbang.o
diff --git a/drivers/net/phy/mdio-aspeed.c b/drivers/net/phy/mdio-aspeed.c
new file mode 100644
index ..cad820568f75
--- /dev/null
+++ b/drivers/net/phy/mdio-aspeed.c
@@ -0,0 +1,157 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/* Copyright (C) 2019 IBM Corp. */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRV_NAME "mdio-aspeed"
+
+#define ASPEED_MDIO_CTRL   0x0
+#define   ASPEED_MDIO_CTRL_FIREBIT(31)
+#define   ASPEED_MDIO_CTRL_ST  BIT(28)
+#define ASPEED_MDIO_CTRL_ST_C450
+#define ASPEED_MDIO_CTRL_ST_C221
+#define   ASPEED_MDIO_CTRL_OP  GENMASK(27, 26)
+#define MDIO_C22_OP_WRITE  0b01
+#define MDIO_C22_OP_READ   0b10
+#define   ASPEED_MDIO_CTRL_PHYAD   GENMASK(25, 21)
+#define   ASPEED_MDIO_CTRL_REGAD   GENMASK(20, 16)
+#define   ASPEED_MDIO_CTRL_MIIWDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_DATA   0x4
+#define   ASPEED_MDIO_DATA_MDC_THRES   GENMASK(31, 24)
+#define   ASPEED_MDIO_DATA_MDIO_EDGE   BIT(23)
+#define   ASPEED_MDIO_DATA_MDIO_LATCH  GENMASK(22, 20)
+#define   ASPEED_MDIO_DATA_IDLEBIT(16)
+#define   ASPEED_MDIO_DATA_MIIRDATAGENMASK(15, 0)
+
+#define ASPEED_MDIO_INTERVAL_US100
+#define ASPEED_MDIO_TIMEOUT_US (ASPEED_MDIO_INTERVAL_US * 10)
+
+struct aspeed_mdio {
+   void __iomem *base;
+};
+
+static int aspeed_mdio_read(struct mii_bus *bus, int addr, int regnum)
+{
+   struct aspeed_mdio *ctx = bus->priv;
+   u32 ctrl;
+   u32 data;
+   int rc;
+
+   dev_dbg(>dev, "%s: addr: %d, regnum: %d\n", __func__, addr,
+   regnum);
+
+   /* Just clause 22 for the moment */
+   if (regnum & MII_ADDR_C45)
+   return -EOPNOTSUPP;
+
+   ctrl = ASPEED_MDIO_CTRL_FIRE
+   | FIELD_PREP(ASPEED_MDIO_CTRL_ST, ASPEED_MDIO_CTRL_ST_C22)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
+   | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, regnum);
+
+   iowrite32(ctrl, ctx->base + ASPEED_MDIO_CTRL);
+
+   rc = readl_poll_timeout(ctx->base + ASPEED_MDIO_DATA, data,
+   data & ASPEED_MDIO_DATA_IDLE,
+   ASPEED_MDIO_INTERVAL_US,
+   ASPEED_MDIO_TIMEOUT_US);
+   if (rc < 0)
+   return rc;
+
+   return 

[PATCH net-next v2 3/4] net: ftgmac100: Add support for DT phy-handle property

[Andrew Jeffery]

phy-handle is necessary for the AST2600 which separates the MDIO
controllers from the MAC.

I've tried to minimise the intrusion of supporting the AST2600 to the
FTGMAC100 by leaving in place the existing MDIO support for the embedded
MDIO interface. The AST2400 and AST2500 continue to be supported this
way, as it avoids breaking/reworking existing devicetrees.

The AST2600 support by contrast requires the presence of the phy-handle
property in the MAC devicetree node to specify the appropriate PHY to
associate with the MAC. In the event that someone wants to specify the
MDIO bus topology under the MAC node on an AST2400 or AST2500, the
current auto-probe approach is done conditional on the absence of an
"mdio" child node of the MAC.

Signed-off-by: Andrew Jeffery 
---
 drivers/net/ethernet/faraday/ftgmac100.c | 37 +---
 1 file changed, 33 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/faraday/ftgmac100.c 
b/drivers/net/ethernet/faraday/ftgmac100.c
index 030fed65393e..563384b788ab 100644
--- a/drivers/net/ethernet/faraday/ftgmac100.c
+++ b/drivers/net/ethernet/faraday/ftgmac100.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1619,8 +1620,13 @@ static int ftgmac100_setup_mdio(struct net_device 
*netdev)
if (!priv->mii_bus)
return -EIO;
 
-   if (priv->is_aspeed) {
-   /* This driver supports the old MDIO interface */
+   if (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
+   of_device_is_compatible(np, "aspeed,ast2500-mac")) {
+   /* The AST2600 has a separate MDIO controller */
+
+   /* For the AST2400 and AST2500 this driver only supports the
+* old MDIO interface
+*/
reg = ioread32(priv->base + FTGMAC100_OFFSET_REVR);
reg &= ~FTGMAC100_REVR_NEW_MDIO_INTERFACE;
iowrite32(reg, priv->base + FTGMAC100_OFFSET_REVR);
@@ -1797,7 +1803,8 @@ static int ftgmac100_probe(struct platform_device *pdev)
 
np = pdev->dev.of_node;
if (np && (of_device_is_compatible(np, "aspeed,ast2400-mac") ||
-  of_device_is_compatible(np, "aspeed,ast2500-mac"))) {
+  of_device_is_compatible(np, "aspeed,ast2500-mac") ||
+  of_device_is_compatible(np, "aspeed,ast2600-mac"))) {
priv->rxdes0_edorr_mask = BIT(30);
priv->txdes0_edotr_mask = BIT(30);
priv->is_aspeed = true;
@@ -1817,7 +1824,29 @@ static int ftgmac100_probe(struct platform_device *pdev)
priv->ndev = ncsi_register_dev(netdev, ftgmac100_ncsi_handler);
if (!priv->ndev)
goto err_ncsi_dev;
-   } else {
+   } else if (np && of_get_property(np, "phy-handle", NULL)) {
+   struct phy_device *phy;
+
+   phy = of_phy_get_and_connect(priv->netdev, np,
+_adjust_link);
+   if (!phy) {
+   dev_err(>dev, "Failed to connect to phy\n");
+   goto err_setup_mdio;
+   }
+
+   /* Indicate that we support PAUSE frames (see comment in
+* Documentation/networking/phy.txt)
+*/
+   phy_support_asym_pause(phy);
+
+   /* Display what we found */
+   phy_attached_info(phy);
+   } else if (np && !of_get_child_by_name(np, "mdio")) {
+   /* Support legacy ASPEED devicetree descriptions that decribe a
+* MAC with an embedded MDIO controller but have no "mdio"
+* child node. Automatically scan the MDIO bus for available
+* PHYs.
+*/
priv->use_ncsi = false;
err = ftgmac100_setup_mdio(netdev);
if (err)
-- 
2.20.1

[PATCH net-next v2 4/4] net: ftgmac100: Select ASPEED MDIO driver for the AST2600

[Andrew Jeffery]

Ensures we can talk to a PHY via MDIO on the AST2600, as the MDIO
controller is now separate from the MAC.

Signed-off-by: Andrew Jeffery 
---
 drivers/net/ethernet/faraday/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/faraday/Kconfig 
b/drivers/net/ethernet/faraday/Kconfig
index a9b105803fb7..73e4f2648e49 100644
--- a/drivers/net/ethernet/faraday/Kconfig
+++ b/drivers/net/ethernet/faraday/Kconfig
@@ -32,6 +32,7 @@ config FTGMAC100
depends on ARM || NDS32 || COMPILE_TEST
depends on !64BIT || BROKEN
select PHYLIB
+   select MDIO_ASPEED if MACH_ASPEED_G6
---help---
  This driver supports the FTGMAC100 Gigabit Ethernet controller
  from Faraday. It is used on Faraday A369, Andes AG102 and some
-- 
2.20.1

[PATCH] ASoC: max98383: add 88200 and 96000 sampling rate support

[chunguo feng]

From: fengchunguo 

88200 and 96000 sampling rate was not enabled on driver, so can't be played.

The error information:
max98373 3-0031：rate 96000 not supported
max98373 3-0031：ASoC: can't set max98373-aif1 hw params: -22

Signed-off-by: fengchunguo 
---
 sound/soc/codecs/max98373.c | 6 ++
 sound/soc/codecs/max98373.h | 2 ++
 2 files changed, 8 insertions(+)
 mode change 100644 => 100755 sound/soc/codecs/max98373.c
 mode change 100644 => 100755 sound/soc/codecs/max98373.h

diff --git a/sound/soc/codecs/max98373.c b/sound/soc/codecs/max98373.c
old mode 100644
new mode 100755
index 528695cd6a1c..8c601a3ebc27
--- a/sound/soc/codecs/max98373.c
+++ b/sound/soc/codecs/max98373.c
@@ -267,6 +267,12 @@ static int max98373_dai_hw_params(struct snd_pcm_substream 
*substream,
case 48000:
sampling_rate = MAX98373_PCM_SR_SET1_SR_48000;
break;
+   case 88200:
+   sampling_rate = MAX98373_PCM_SR_SET1_SR_88200;
+   break;
+   case 96000:
+   sampling_rate = MAX98373_PCM_SR_SET1_SR_96000;
+   break;
default:
dev_err(component->dev, "rate %d not supported\n",
params_rate(params));
diff --git a/sound/soc/codecs/max98373.h b/sound/soc/codecs/max98373.h
old mode 100644
new mode 100755
index f6a37aa02f26..a59e51355a84
--- a/sound/soc/codecs/max98373.h
+++ b/sound/soc/codecs/max98373.h
@@ -130,6 +130,8 @@
 #define MAX98373_PCM_SR_SET1_SR_32000 (0x6 << 0)
 #define MAX98373_PCM_SR_SET1_SR_44100 (0x7 << 0)
 #define MAX98373_PCM_SR_SET1_SR_48000 (0x8 << 0)
+#define MAX98373_PCM_SR_SET1_SR_88200 (0x9 << 0)
+#define MAX98373_PCM_SR_SET1_SR_96000 (0xA << 0)
 
 /* MAX98373_R2028_PCM_SR_SETUP_2 */
 #define MAX98373_PCM_SR_SET2_SR_MASK (0xF << 4)
-- 
2.22.0

[PATCH net-next v2 1/4] dt-bindings: net: Add aspeed,ast2600-mdio binding

[Andrew Jeffery]

The AST2600 splits out the MDIO bus controller from the MAC into its own
IP block and rearranges the register layout. Add a new binding to
describe the new hardware.

Signed-off-by: Andrew Jeffery 

---
v2:
* aspeed: Utilise mdio.yaml
* aspeed: Drop status from example
---
 .../bindings/net/aspeed,ast2600-mdio.yaml | 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml

diff --git a/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml 
b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
new file mode 100644
index ..71808e78a495
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/aspeed,ast2600-mdio.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/aspeed,ast2600-mdio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2600 MDIO Controller
+
+maintainers:
+  - Andrew Jeffery 
+
+description: |+
+  The ASPEED AST2600 MDIO controller is the third iteration of ASPEED's MDIO
+  bus register interface, this time also separating out the controller from the
+  MAC.
+
+allOf:
+  - $ref: "mdio.yaml#"
+
+properties:
+  compatible:
+const: aspeed,ast2600-mdio
+  reg:
+maxItems: 1
+description: The register range of the MDIO controller instance
+
+required:
+  - compatible
+  - reg
+  - "#address-cells"
+  - "#size-cells"
+
+examples:
+  - |
+mdio0: mdio@1e65 {
+compatible = "aspeed,ast2600-mdio";
+reg = <0x1e65 0x8>;
+#address-cells = <1>;
+#size-cells = <0>;
+
+ethphy0: ethernet-phy@0 {
+compatible = "ethernet-phy-ieee802.3-c22";
+reg = <0>;
+};
+};
-- 
2.20.1

[RFC PATCH] compiler_attributes.h: Add 'fallthrough' pseudo keyword for switch/case use

[Joe Perches]

Reserve the pseudo keyword 'fallthrough' for the ability to convert the
various case block /* fallthrough */ style comments to appear to be an
actual reserved word with the same gcc case block missing fallthrough
warning capability.

All switch/case blocks now must end in one of:

break;
fallthrough;
goto ;
return [expression];

fallthough is gcc's __attribute__((__fallthrough__)) which was introduced
in gcc version 7..

fallthrough devolves to an empty "do {} while (0)" if the compiler version
(any version less than gcc 7) does not support the attribute.

Signed-off-by: Joe Perches 
---

For allow compilation of a kernel that includes net/sctp, this patch
also requires a rename of the use of fallthrough as a label in
net/sctp/sm_make_chunk.c that was submitted as:

https://lore.kernel.org/lkml/e0dd3af448e38e342c1ac6e7c0c802696eb77fd6.1564549413.git@perches.com/

 include/linux/compiler_attributes.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/linux/compiler_attributes.h 
b/include/linux/compiler_attributes.h
index 6b318efd8a74..cdf016596659 100644
--- a/include/linux/compiler_attributes.h
+++ b/include/linux/compiler_attributes.h
@@ -40,6 +40,7 @@
 # define __GCC4_has_attribute___noclone__ 1
 # define __GCC4_has_attribute___nonstring__   0
 # define __GCC4_has_attribute___no_sanitize_address__ (__GNUC_MINOR__ >= 8)
+# define __GCC4_has_attribute___fallthrough__ 0
 #endif
 
 /*
@@ -185,6 +186,22 @@
 # define __noclone
 #endif
 
+/*
+ * Add the pseudo keyword 'fallthrough' so case statement blocks
+ * must end with any of these keywords:
+ *   break;
+ *   fallthrough;
+ *   goto ;
+ *   return [expression];
+ *
+ *  gcc: 
https://gcc.gnu.org/onlinedocs/gcc/Statement-Attributes.html#Statement-Attributes
+ */
+#if __has_attribute(__fallthrough__)
+# define fallthrough__attribute__((__fallthrough__))
+#else
+# define fallthroughdo {} while (0)  /* fallthrough */
+#endif
+
 /*
  * Note the missing underscores.
  *
-- 
2.15.0

Re: "mm: account nr_isolated_xxx in [isolate|putback]_lru_page" breaks OOM with swap

[Minchan Kim]

On Tue, Jul 30, 2019 at 12:25:28PM -0400, Qian Cai wrote:
> OOM workloads with swapping is unable to recover with linux-next since next-
> 20190729 due to the commit "mm: account nr_isolated_xxx in
> [isolate|putback]_lru_page" breaks OOM with swap" [1]
> 
> [1] 
> https://lore.kernel.org/linux-mm/20190726023435.214162-4-minc...@kernel.org/
> T/#mdcd03bcb4746f2f23e6f508c205943726aee8355
> 
> For example, LTP oom01 test case is stuck for hours, while it finishes in a 
> few
> minutes here after reverted the above commit. Sometimes, it prints those 
> message
> while hanging.
> 
> [  509.983393][  T711] INFO: task oom01:5331 blocked for more than 122 
> seconds.
> [  509.983431][  T711]   Not tainted 5.3.0-rc2-next-20190730 #7
> [  509.983447][  T711] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
> disables this message.
> [  509.983477][  T711] oom01   D24656  5331   5157 0x0004
> [  509.983513][  T711] Call Trace:
> [  509.983538][  T711] [c00020037d00f880] [0008] 0x8 (unreliable)
> [  509.983583][  T711] [c00020037d00fa60] [c0023724]
> __switch_to+0x3a4/0x520
> [  509.983615][  T711] [c00020037d00fad0] [c08d17bc]
> __schedule+0x2fc/0x950
> [  509.983647][  T711] [c00020037d00fba0] [c08d1e68] 
> schedule+0x58/0x150
> [  509.983684][  T711] [c00020037d00fbd0] [c08d7614]
> rwsem_down_read_slowpath+0x4b4/0x630
> [  509.983727][  T711] [c00020037d00fc90] [c08d7dfc]
> down_read+0x12c/0x240
> [  509.983758][  T711] [c00020037d00fd20] [c005fb28]
> __do_page_fault+0x6f8/0xee0
> [  509.983801][  T711] [c00020037d00fe20] [c000a364]
> handle_page_fault+0x18/0x38

Thanks for the testing! No surprise the patch make some bugs because
it's rather tricky.

Could you test this patch?

>From b31667210dd747f4d8aeb7bdc1f5c14f1f00bff5 Mon Sep 17 00:00:00 2001
From: Minchan Kim 
Date: Wed, 31 Jul 2019 14:18:01 +0900
Subject: [PATCH] mm: decrease NR_ISOALTED count at succesful migration

If migration fails, it should go back to LRU list so putback_lru_page
could handle NR_ISOLATED count in pair with isolate_lru_page. However,
if migration is successful, the page will be freed so no need to
add the page back to LRU list. Thus, NR_ISOLATED count should be done
in manually.

Signed-off-by: Minchan Kim 
---
 mm/migrate.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/mm/migrate.c b/mm/migrate.c
index 84b89d2d69065..96ae0c3cada8d 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1166,6 +1166,7 @@ static ICE_noinline int unmap_and_move(new_page_t 
get_new_page,
 {
int rc = MIGRATEPAGE_SUCCESS;
struct page *newpage;
+   bool is_lru = __PageMovable(page);
 
if (!thp_migration_supported() && PageTransHuge(page))
return -ENOMEM;
@@ -1175,17 +1176,10 @@ static ICE_noinline int unmap_and_move(new_page_t 
get_new_page,
return -ENOMEM;
 
if (page_count(page) == 1) {
-   bool is_lru = !__PageMovable(page);
-
/* page was freed from under us. So we are done. */
ClearPageActive(page);
ClearPageUnevictable(page);
-   if (likely(is_lru))
-   mod_node_page_state(page_pgdat(page),
-   NR_ISOLATED_ANON +
-   page_is_file_cache(page),
-   -hpage_nr_pages(page));
-   else {
+   if (unlikely(!is_lru)) {
lock_page(page);
if (!PageMovable(page))
__ClearPageIsolated(page);
@@ -1229,6 +1223,12 @@ static ICE_noinline int unmap_and_move(new_page_t 
get_new_page,
if (set_hwpoison_free_buddy_page(page))
num_poisoned_pages_inc();
}
+
+   if (likely(is_lru))
+   mod_node_page_state(page_pgdat(page),
+   NR_ISOLATED_ANON +
+   page_is_file_cache(page),
+   -hpage_nr_pages(page));
} else {
if (rc != -EAGAIN) {
if (likely(!__PageMovable(page))) {
-- 
2.22.0.709.g102302147b-goog

linux-next: build failure after merge of the pm tree

[Stephen Rothwell]

Hi all,

After merging the pm tree, today's linux-next build (x86_64 allnoconfig)
failed like this:

x86_64-linux-gnu-ld: kernel/sched/core.o: in function `cpuidle_poll_time':
core.c:(.text+0x230): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/loadavg.o: in function `cpuidle_poll_time':
loadavg.c:(.text+0x0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/clock.o: in function `cpuidle_poll_time':
clock.c:(.text+0x0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/cputime.o: in function `cpuidle_poll_time':
cputime.c:(.text+0x0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/idle.o: in function `cpuidle_poll_time':
idle.c:(.text+0xd0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/fair.o: in function `cpuidle_poll_time':
fair.c:(.text+0xb20): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/rt.o: in function `cpuidle_poll_time':
rt.c:(.text+0x790): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/deadline.o: in function `cpuidle_poll_time':
deadline.c:(.text+0xce0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/wait.o: in function `cpuidle_poll_time':
wait.c:(.text+0x1d0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/wait_bit.o: in function `cpuidle_poll_time':
wait_bit.c:(.text+0x50): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/swait.o: in function `cpuidle_poll_time':
swait.c:(.text+0x30): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here
x86_64-linux-gnu-ld: kernel/sched/completion.o: in function `cpuidle_poll_time':
completion.c:(.text+0x0): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here

Caused by commit

  259231a04561 ("cpuidle: add poll_limit_ns to cpuidle_device structure")

I have added the following patch for today:

From: Stephen Rothwell 
Date: Wed, 31 Jul 2019 15:29:52 +1000
Subject: [PATCH] cpuidle: header file stubs must be "static inline"

An x86_64 allmodconfig build produces these errors:

x86_64-linux-gnu-ld: kernel/sched/core.o: in function `cpuidle_poll_time':
core.c:(.text+0x230): multiple definition of `cpuidle_poll_time'; 
arch/x86/kernel/process.o:process.c:(.text+0xc0): first defined here

(and more)

Fixes: 259231a04561 ("cpuidle: add poll_limit_ns to cpuidle_device structure")
Signed-off-by: Stephen Rothwell 
---
 include/linux/cpuidle.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/cpuidle.h b/include/linux/cpuidle.h
index ba535a1a47d5..1a9f54eb3aa1 100644
--- a/include/linux/cpuidle.h
+++ b/include/linux/cpuidle.h
@@ -170,7 +170,7 @@ static inline int cpuidle_enter(struct cpuidle_driver *drv,
struct cpuidle_device *dev, int index)
 {return -ENODEV; }
 static inline void cpuidle_reflect(struct cpuidle_device *dev, int index) { }
-extern u64 cpuidle_poll_time(struct cpuidle_driver *drv,
+static inline u64 cpuidle_poll_time(struct cpuidle_driver *drv,
 struct cpuidle_device *dev)
 {return 0; }
 static inline int cpuidle_register_driver(struct cpuidle_driver *drv)
-- 
2.20.1

-- 
Cheers,
Stephen Rothwell


pgpreez2g934_.pgp
Description: OpenPGP digital signature

Re: [PATCH 4.14 000/293] 4.14.135-stable review

[Kelsey Skunberg]

On Mon, Jul 29, 2019 at 09:18:11PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.135 release.
> There are 293 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 31 Jul 2019 07:05:01 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.135-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.14.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no regressions on my system.

Cheers,
Kelsey 

Re: [PATCH 4.19 000/113] 4.19.63-stable review

[Kelsey Skunberg]

On Mon, Jul 29, 2019 at 09:21:27PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.63 release.
> There are 113 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 31 Jul 2019 07:05:01 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.19.63-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.19.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no regressions on my system.

Cheers,
Kelsey 

Re: [PATCH 5.2 000/215] 5.2.5-stable review

[Kelsey Skunberg]

On Mon, Jul 29, 2019 at 09:19:56PM +0200, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.2.5 release.
> There are 215 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Wed 31 Jul 2019 07:05:01 PM UTC.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.2.5-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-5.2.y
> and the diffstat can be found below.
> 
> thanks,
> 
> greg k-h

Compiled and booted with no regressions on my system.

Cheers,
Kelsey

[PATCH v2] watchdog: pc87413: Rewriting of pc87413_wdt driver to use watchdog subsystem

[Mark Balantzyan]

This patch rewrites the pc87413_wdt driver to use the watchdog subsystem. In
doing so, it also addresses a potential race condition owing from the
swc_base_addr variable being used before being set.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig   |   1 +
 drivers/watchdog/pc87413_wdt.c | 333 +
 2 files changed, 47 insertions(+), 287 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..84a7326d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1166,6 +1166,7 @@ config SCx200_WDT
 
 config PC87413_WDT
tristate "NS PC87413 watchdog"
+   select WATCHDOG_CORE
depends on X86
---help---
  This is the driver for the hardware watchdog on the PC87413 chipset
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 06a892e3..19d29cd8 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -22,15 +22,9 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -60,13 +54,9 @@ static int swc_base_addr = -1;
 
 static int timeout = DEFAULT_TIMEOUT;  /* timeout value */
 static unsigned long timer_enabled;/* is the timer enabled? */
-
-static char expect_close;  /* is the close expected? */
-
-static DEFINE_SPINLOCK(io_lock);   /* to guard us from io races */
-
 static bool nowayout = WATCHDOG_NOWAYOUT;
 
+
 /* -- Low level function */
 
 /* Select pins for Watchdog output */
@@ -151,13 +141,15 @@ static inline void pc87413_swc_bank3(void)
 
 /* Set watchdog timeout to x minutes */
 
-static inline void pc87413_programm_wdto(char pc87413_time)
+static int pc87413_set_timeout(struct watchdog_device *wdd, unsigned int t)
 {
-   /* Step 5: Programm WDTO, Twd. */
-   outb_p(pc87413_time, swc_base_addr + WDTO);
-#ifdef DEBUG
-   pr_info(DPFX "Set WDTO to %d minutes\n", pc87413_time);
-#endif
+   /* Step 5: Programm watchdog timeout */
+
+   if ((t < 1) || ( t > 60))/* arbitrary upper limit */
+   return -EINVAL;
+   
+   timeout = t;
+   return 0;
 }
 
 /* Enable WDEN */
@@ -216,281 +208,61 @@ static inline void pc87413_disable_sw_wd_trg(void)
 
 /* -- Higher level functions */
 
-/* Enable the watchdog */
+/* Enable/start the watchdog */
 
-static void pc87413_enable(void)
+static int pc87413_start(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
+   return 0;
 }
 
-/* Disable the watchdog */
+/* Disable/stop the watchdog */
 
-static void pc87413_disable(void)
+static int pc87413_stop(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(0);
-
-   spin_unlock(_lock);
+   pc87413_set_timeout(wdd,0);
+   return 0;
 }
 
-/* Refresh the watchdog */
+/* Refresh/keepalive the watchdog */
 
-static void pc87413_refresh(void)
+static int pc87413_keepalive(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
-}
-
-/* -- File operations ---*/
-
-/**
- * pc87413_open:
- * @inode: inode of device
- * @file: file handle to device
- *
- */
-
-static int pc87413_open(struct inode *inode, struct file *file)
-{
-   /* /dev/watchdog can only be opened once */
-
-   if (test_and_set_bit(0, _enabled))
-   return -EBUSY;
-
-   if (nowayout)
-   __module_get(THIS_MODULE);
-
-   /* Reload and activate timer */
-   pc87413_refresh();
-
-   pr_info("Watchdog enabled. Timeout set to %d minute(s).\n", timeout);
-
-   return nonseekable_open(inode, file);
-}
-
-/**
- * pc87413_release:
- * @inode: inode to board
- * @file: file handle to board
- *
- * The watchdog has a configurable API. There is a religious dispute
- * between people who want their watchdog to be able to shut down and
- * those who want to be sure if the watchdog manager dies the machine
- * reboots. In the former case we disable the counters, in the latter
- * case you have to open it again very soon.
- */
-
-static int pc87413_release(struct inode *inode, struct file *file)
-{
-  

Re: [PATCH] watchdog: pc87413: Rewriting of pc87413_wdt driver to use watchdog subsystem

[Mark Balantzyan]

Hi all, Guenter,

Thank you for your email. Unfortunately, on my end, the indentation is
straight and perhaps through protocol transfer there was stray
modification.

I've made the other changes as indicated that I'll submit in a v2 patch 
shortly. Is 'v2' permissible to include in the title in this case? Not 
sure, but this will BE a modification...in that case I should have been 
v-ing my patches since.


No, the compiler did not complain about no 'return ret' as part of the 
label code block. The function does 'return 0;' at the end, by default.


Thanks + regards,
Mark

Re: [PATCH] PM/sleep: Expose suspend stats in sysfs

[Greg KH]

On Tue, Jul 30, 2019 at 03:52:28PM -0700, Kalesh Singh wrote:
> +#define suspend_attr(_name)  \
> +static ssize_t _name##_show(struct kobject *kobj,\
> + struct kobj_attribute *attr, char *buf) \
> +{\
> + int index;  \
> + enum suspend_stat_step step;\
> + char *last_failed_stat = NULL;  \
> + \
> + if (strcmp(attr->attr.name, "last_failed_dev") == 0) {  \
> + index = suspend_stats._name + REC_FAILED_NUM - 1;   \
> + index %= REC_FAILED_NUM;\
> + last_failed_stat = suspend_stats.failed_devs[index];\
> + return sprintf(buf, "%s\n", last_failed_stat);  \
> + } else if (strcmp(attr->attr.name, "last_failed_step") == 0) {  \
> + index = suspend_stats._name + REC_FAILED_NUM - 1;   \
> + index %= REC_FAILED_NUM;\
> + step = suspend_stats.failed_steps[index];   \
> + last_failed_stat = suspend_step_name(step); \
> + return sprintf(buf, "%s\n", last_failed_stat);  \
> + } else if (strcmp(attr->attr.name, "last_failed_errno") == 0) { \
> + index = suspend_stats._name + REC_FAILED_NUM - 1;   \
> + index %= REC_FAILED_NUM;\
> + return sprintf(buf, "%d\n", suspend_stats.errno[index]);\
> + }   \

For these 3 "special" ones, just have your own show function, no need to
cram it into this macro, making a bunch of unused code be generated all
the time.

thanks,

greg k-h

[PATCH] net: sctp: Rename fallthrough label to unhandled

[Joe Perches]

fallthrough may become a pseudo reserved keyword so this only use of
fallthrough is better renamed to allow it.

Signed-off-by: Joe Perches 
---
 net/sctp/sm_make_chunk.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 36bd8a6e82df..3fdcaa2fbf12 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2152,7 +2152,7 @@ static enum sctp_ierror sctp_verify_param(struct net *net,
case SCTP_PARAM_SET_PRIMARY:
if (net->sctp.addip_enable)
break;
-   goto fallthrough;
+   goto unhandled;
 
case SCTP_PARAM_HOST_NAME_ADDRESS:
/* Tell the peer, we won't support this param.  */
@@ -2163,11 +2163,11 @@ static enum sctp_ierror sctp_verify_param(struct net 
*net,
case SCTP_PARAM_FWD_TSN_SUPPORT:
if (ep->prsctp_enable)
break;
-   goto fallthrough;
+   goto unhandled;
 
case SCTP_PARAM_RANDOM:
if (!ep->auth_enable)
-   goto fallthrough;
+   goto unhandled;
 
/* SCTP-AUTH: Secion 6.1
 * If the random number is not 32 byte long the association
@@ -2184,7 +2184,7 @@ static enum sctp_ierror sctp_verify_param(struct net *net,
 
case SCTP_PARAM_CHUNKS:
if (!ep->auth_enable)
-   goto fallthrough;
+   goto unhandled;
 
/* SCTP-AUTH: Section 3.2
 * The CHUNKS parameter MUST be included once in the INIT or
@@ -2200,7 +2200,7 @@ static enum sctp_ierror sctp_verify_param(struct net *net,
 
case SCTP_PARAM_HMAC_ALGO:
if (!ep->auth_enable)
-   goto fallthrough;
+   goto unhandled;
 
hmacs = (struct sctp_hmac_algo_param *)param.p;
n_elt = (ntohs(param.p->length) -
@@ -2223,7 +2223,7 @@ static enum sctp_ierror sctp_verify_param(struct net *net,
retval = SCTP_IERROR_ABORT;
}
break;
-fallthrough:
+unhandled:
default:
pr_debug("%s: unrecognized param:%d for chunk:%d\n",
 __func__, ntohs(param.p->type), cid);
-- 
2.15.0

Re: [PATCH v8 00/14] Rockchip ISP1 Driver

[Hans Verkuil]

On 7/31/19 6:33 AM, Hans Verkuil wrote:
> On 7/31/19 6:29 AM, Hans Verkuil wrote:
>> On 7/31/19 2:08 AM, Helen Koike wrote:
>>>
>>>
>>> On 7/30/19 5:50 PM, Helen Koike wrote:


 On 7/30/19 5:15 PM, Hans Verkuil wrote:
> On 7/30/19 8:42 PM, Helen Koike wrote:
>> Hello,
>>
>> I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
>> rk3399 SoC.
>>
>> I didn't change much from the last version, just applying the
>> suggestions made in the previous one.
>>
>> This patchset is also available at:
>> https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v8
>>
>> Libcamera patched to work with this version:
>> https://gitlab.collabora.com/koike/libcamera
>> (also sent to the mailing list)
>>
>> I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
>> Scarlet Chromebook.
>>
>> Known issues (same as in v7):
>> -
>> - Reloading the module doesn't work (there is some missing cleanup when
>> unloading)
>> - When capturing in bayer format, changing the size doesn't seem to
>> affect the image.
>> - crop needs more tests
>> - v4l2-compliance error:
>> fail: v4l2-test-controls.cpp(824): subscribe event for control 
>> 'Image Processing Controls' failed
>> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>
> Can you mail me the full v4l2-compliance output?

 Sure, please check here: http://ix.io/1Q5u
 I updated v4l-utils with the latest version and I re-ran 
 bootstrap/configure/make,
 but for some reason the hash from the link above is not the latest commit, 
 probably some
 old configuration somewhere. I'll resend this log as soon as I get 
 v4l2-compliance
 properly updated.
>>>
>>> Please see the output of v4l2-compliance here with an updated v4l-utils: 
>>> http://ix.io/1Q6A
>>
>> So this FAIL is for /dev/v4l-subdev0 (rkisp1-isp-subdev).
>>
>> What is weird that this subdev does not appear to have controls at all.
>>
>> What is the output of 'v4l2-ctl -d /dev/v4l-subdev0 -l'? And if it lists
>> controls, then why?
>>
>> If you run 'v4l2-compliance -u /dev/v4l-subdev0', do you get a fail as
>> well?
> 
> I see the same issue with v4l-subdev1, but I see no "Media Driver Info"
> in the v4l2-compliance output for that subdev. That's strange. It would
> be good to know why that's happening.

It looks to be some parenting issue: v4l2-compliance expects to find
a mediaX directory in /sys/dev/char/81\:Y/device/ where 81:Y is the major/minor
of /dev/v4l-subdev1.

Because is this mi_get_media_fd() cannot find the media device for the subdev
in v4l2-compliance.

Regards,

Hans

Re: [PATCH v2 5/5] dt-bindings: Update the isa string description

[Paul Walmsley]

On Tue, 30 Jul 2019, Atish Patra wrote:

> The yaml documentation description of isa strings section doesn't
> specify anything about the case sensitiveness of the isa strings.
> The RISC-V specification clearly specifies it to be case insensitive.
> However, Linux kernel supports only lower case isa strings.

The DT binding documentation specifies an interface.  As such the binding 
isn't determined by any particular piece of software.  So justifying the 
binding update by referring to what the Linux kernel currently supports 
isn't that relevant.  If you still really believe that software should be 
required to handle mixed-case DT ISA strings, the right answer would be to 
change the software, as your original patches proposed.  The way you've 
written this patch description, it sounds like you still don't agree with 
the conclusion that a strictly lowercase string is a good approach.

If I've misunderstood your intent here, and you do think that specifying 
an all lowercase string is sufficient, then instead of the patch 
description above, how about something like:

"Since the RISC-V specification states that ISA description strings are 
case-insensitive, there's no functional difference between mixed-case, 
upper-case, and lower-case ISA strings.  Thus, to simplify parsing, 
specify that the letters present of riscv,isa must be all lowercase."

That way it's clear that, per the RISC-V specification, there's no 
functional difference associated with case.

However, if what you're saying is that you still don't like this outcome, 
let me know and I'll write the patch myself.  That way you don't have to 
have your name associated with a change that you don't believe in.

> Update the yaml documentation accordingly to avoid any confusion.
> 
> Signed-off-by: Atish Patra 
> ---
>  Documentation/devicetree/bindings/riscv/cpus.yaml | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml 
> b/Documentation/devicetree/bindings/riscv/cpus.yaml
> index c899111aa5e3..e22a2b7ebafa 100644
> --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> @@ -46,10 +46,14 @@ properties:
>- rv64imafdc
>  description:
>Identifies the specific RISC-V instruction set architecture
> -  supported by the hart.  These are documented in the RISC-V
> +  supported by the hart. These are documented in the RISC-V
>User-Level ISA document, available from
>https://riscv.org/specifications/
>  
> +  Linux kernel only supports lower case isa strings. Thus,

In the past, the DT maintainers have pushed back against explicitly 
mentioning the Linux kernel in binding documentation, since the DT 
bindings define an interface that's independent of the underlying software 
implementation.  How about just stating something like "Letters in the 
riscv,isa string must be all lowercase" ?

> +  isa strings must be specified in lower case in device tree
> +  as well.
> +

- Paul

Re: [PATCH] watchdog: pc87413: Rewriting of pc87413_wdt driver to use watchdog subsystem

[Guenter Roeck]

On 7/30/19 8:22 PM, Mark Balantzyan wrote:

This patch rewrites the pc87413_wdt driver to use the watchdog subsystem. In
doing so, it also addresses a potential race condition owing from the
swc_base_addr variable being used before being set.

Signed-off-by: Mark Balantzyan 

---
  drivers/watchdog/Kconfig   |   1 +
  drivers/watchdog/pc87413_wdt.c | 323 -
  2 files changed, 40 insertions(+), 284 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..84a7326d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1166,6 +1166,7 @@ config SCx200_WDT
  
  config PC87413_WDT

tristate "NS PC87413 watchdog"
+   select WATCHDOG_CORE
depends on X86
---help---
  This is the driver for the hardware watchdog on the PC87413 chipset
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 06a892e3..60e3cda6 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -22,15 +22,9 @@
  
  #include 

  #include 
-#include 
  #include 
  #include 
  #include 
-#include 
-#include 
-#include 
-#include 
-#include 
  #include 
  #include 
  #include 
@@ -60,13 +54,9 @@ static int swc_base_addr = -1;
  
  static int timeout = DEFAULT_TIMEOUT;	/* timeout value */

  static unsigned long timer_enabled;   /* is the timer enabled? */
-
-static char expect_close;  /* is the close expected? */
-
-static DEFINE_SPINLOCK(io_lock);   /* to guard us from io races */
-
  static bool nowayout = WATCHDOG_NOWAYOUT;
  
+

  /* -- Low level function */
  
  /* Select pins for Watchdog output */

@@ -151,13 +141,15 @@ static inline void pc87413_swc_bank3(void)
  
  /* Set watchdog timeout to x minutes */
  
-static inline void pc87413_programm_wdto(char pc87413_time)

+static int pc87413_set_timeout(struct watchdog_device *wdd, unsigned int t)
  {
-   /* Step 5: Programm WDTO, Twd. */
-   outb_p(pc87413_time, swc_base_addr + WDTO);
-#ifdef DEBUG
-   pr_info(DPFX "Set WDTO to %d minutes\n", pc87413_time);
-#endif
+   /* Step 5: Programm watchdog timeout */
+
+   if ((t < 1) || ( t > 60))/* arbitrary upper limit */
+   return -EINVAL;
+   
+   timeout = t;
+   return 0;
  }
  
  /* Enable WDEN */

@@ -216,281 +208,61 @@ static inline void pc87413_disable_sw_wd_trg(void)
  
  /* -- Higher level functions */
  
-/* Enable the watchdog */

+/* Enable/start the watchdog */
  
-static void pc87413_enable(void)

+static int pc87413_start(struct watchdog_device *wdd)
  {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
+   return 0;
  }
  
-/* Disable the watchdog */

+/* Disable/stop the watchdog */
  
-static void pc87413_disable(void)

+static int pc87413_stop(struct watchdog_device *wdd)
  {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(0);
-
-   spin_unlock(_lock);
+   pc87413_set_timeout(wdd,0);
+   return 0;
  }
  
-/* Refresh the watchdog */

+/* Refresh/keepalive the watchdog */
  
-static void pc87413_refresh(void)

+static int pc87413_keepalive(struct watchdog_device *wdd)
  {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
-}
-
-/* -- File operations ---*/
-
-/**
- * pc87413_open:
- * @inode: inode of device
- * @file: file handle to device
- *
- */
-
-static int pc87413_open(struct inode *inode, struct file *file)
-{
-   /* /dev/watchdog can only be opened once */
-
-   if (test_and_set_bit(0, _enabled))
-   return -EBUSY;
-
-   if (nowayout)
-   __module_get(THIS_MODULE);
-
-   /* Reload and activate timer */
-   pc87413_refresh();
-
-   pr_info("Watchdog enabled. Timeout set to %d minute(s).\n", timeout);
-
-   return nonseekable_open(inode, file);
-}
-
-/**
- * pc87413_release:
- * @inode: inode to board
- * @file: file handle to board
- *
- * The watchdog has a configurable API. There is a religious dispute
- * between people who want their watchdog to be able to shut down and
- * those who want to be sure if the watchdog manager dies the machine
- * reboots. In the former case we disable the counters, in the latter
- * case you have to open it 

[PATCH v2] MIPS: Ingenic: Fix bugs when detecting X1000's parameters.

[Zhou Yanjie]

1.fix bugs when detecting L2 cache sets value.
2.fix bugs when detecting L2 cache ways value.
3.fix bugs when calculate bogoMips and loops_per_jiffy.

Signed-off-by: Zhou Yanjie 
---
 arch/mips/include/asm/mipsregs.h |  1 +
 arch/mips/kernel/cpu-probe.c |  7 +++
 arch/mips/mm/sc-mips.c   | 18 +++---
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/arch/mips/include/asm/mipsregs.h b/arch/mips/include/asm/mipsregs.h
index 1e6966e..01e0fcb 100644
--- a/arch/mips/include/asm/mipsregs.h
+++ b/arch/mips/include/asm/mipsregs.h
@@ -2813,6 +2813,7 @@ __BUILD_SET_C0(status)
 __BUILD_SET_C0(cause)
 __BUILD_SET_C0(config)
 __BUILD_SET_C0(config5)
+__BUILD_SET_C0(config7)
 __BUILD_SET_C0(intcontrol)
 __BUILD_SET_C0(intctl)
 __BUILD_SET_C0(srsmap)
diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index eb527a1..547c9a0 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1964,6 +1964,13 @@ static inline void cpu_probe_ingenic(struct cpuinfo_mips 
*c, unsigned int cpu)
c->cputype = CPU_XBURST;
c->writecombine = _CACHE_UNCACHED_ACCELERATED;
__cpu_name[cpu] = "Ingenic XBurst";
+   /*
+* config7 bit 4 is used to control a low-power mode in
+* XBurst architecture. This mode may cause errors in the
+* calculation of bogomips and loops_per_jiffy, set config7
+* bit 4 to disable this feature to prevent that.
+*/
+   set_c0_config7(BIT(4));
break;
default:
panic("Unknown Ingenic Processor ID!");
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index 9385ddb..ed953d4 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -215,6 +215,14 @@ static inline int __init mips_sc_probe(void)
else
return 0;
 
+   /*
+* According to config2 it would be 512-sets, but that is contradicted
+* by all documentation.
+*/
+   if (current_cpu_type() == CPU_XBURST &&
+   mips_machtype == MACH_INGENIC_X1000)
+   c->scache.sets = 256;
+
tmp = (config2 >> 0) & 0x0f;
if (tmp <= 7)
c->scache.ways = tmp + 1;
@@ -225,9 +233,13 @@ static inline int __init mips_sc_probe(void)
 * According to config2 it would be 5-ways, but that is contradicted
 * by all documentation.
 */
-   if (current_cpu_type() == CPU_XBURST &&
-   mips_machtype == MACH_INGENIC_JZ4770)
-   c->scache.ways = 4;
+   if (current_cpu_type() == CPU_XBURST) {
+   switch (mips_machtype) {
+   case MACH_INGENIC_JZ4770:
+   case MACH_INGENIC_X1000:
+   c->scache.ways = 4;
+   }
+   }
 
c->scache.waysize = c->scache.sets * c->scache.linesz;
c->scache.waybit = __ffs(c->scache.waysize);
-- 
2.7.4

MIPS: Ingenic: Fix bugs when detecting X1000's parameters v2.

[Zhou Yanjie]

v1->v2: Use "set_c0_config7(BIT(4))" to simplify code and add comment.

[PATCH V2] IB/core: Add mitigation for Spectre V1

[Luck, Tony]

Some processors may mispredict an array bounds check and
speculatively access memory that they should not. With
a user supplied array index we like to play things safe
by masking the value with the array size before it is
used as an index.

Signed-off-by: Tony Luck 

---
V2: Mask the index *AFTER* the bounds check. Issue pointed
out by Gustavo. Fix suggested by Ira.

 drivers/infiniband/core/user_mad.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/infiniband/core/user_mad.c 
b/drivers/infiniband/core/user_mad.c
index 9f8a48016b41..32cea5ed9ce1 100644
--- a/drivers/infiniband/core/user_mad.c
+++ b/drivers/infiniband/core/user_mad.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -888,7 +889,12 @@ static int ib_umad_unreg_agent(struct ib_umad_file *file, 
u32 __user *arg)
mutex_lock(>port->file_mutex);
mutex_lock(>mutex);
 
-   if (id >= IB_UMAD_MAX_AGENTS || !__get_agent(file, id)) {
+   if (id >= IB_UMAD_MAX_AGENTS) {
+   ret = -EINVAL;
+   goto out;
+   }
+   id = array_index_nospec(id, IB_UMAD_MAX_AGENTS);
+   if (!__get_agent(file, id)) {
ret = -EINVAL;
goto out;
}
-- 
2.20.1

mmotm 2019-07-30-21-37 uploaded

[akpm]

The mm-of-the-moment snapshot 2019-07-30-21-37 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (5.x
or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/



The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/cgit.cgi/linux-mmots.git/

and use of this tree is similar to
http://git.cmpxchg.org/cgit.cgi/linux-mmotm.git/, described above.


This mmotm tree contains the following patches against 5.3-rc2:
(patches marked "*" will be included in linux-next)

  origin.patch
* docs-signal-fix-a-kernel-doc-markup.patch
* revert-kmemleak-allow-to-coexist-with-fault-injection.patch
* ocfs2-remove-set-but-not-used-variable-last_hash.patch
* 
mm-vmscan-check-if-mem-cgroup-is-disabled-or-not-before-calling-memcg-slab-shrinker.patch
* 
mm-migrate-fix-reference-check-race-between-__find_get_block-and-migration.patch
* 
mm-compaction-avoid-100%-cpu-usage-during-compaction-when-a-task-is-killed.patch
* kasan-remove-clang-version-check-for-kasan_stack.patch
* ubsan-build-ubsanc-more-conservatively.patch
* page-flags-prioritize-kasan-bits-over-last-cpuid.patch
* page-flags-prioritize-kasan-bits-over-last-cpuid-fix.patch
* coredump-split-pipe-command-whitespace-before-expanding-template.patch
* mm-migrate-initialize-pud_entry-in-migrate_vma.patch
* mm-hotplug-remove-unneeded-return-for-void-function.patch
* cgroup-kselftest-relax-fs_spec-checks.patch
* asm-generic-fix-wtype-limits-compiler-warnings.patch
* asm-generic-fix-wtype-limits-compiler-warnings-fix.patch
* asm-generic-fix-wtype-limits-compiler-warnings-v2.patch
* test_meminit-use-gfp_atomic-in-rcu-critical-section.patch
* proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch
* proc-kpageflags-do-not-use-uninitialized-struct-pages.patch
* mm-document-zone-device-struct-page-field-usage.patch
* mm-hmm-fix-zone_device-anon-page-mapping-reuse.patch
* mm-hmm-fix-bad-subpage-pointer-in-try_to_unmap_one.patch
* mm-hmm-fix-bad-subpage-pointer-in-try_to_unmap_one-v3.patch
* acpi-scan-acquire-device_hotplug_lock-in-acpi_scan_init.patch
* 
mm-mempolicy-make-the-behavior-consistent-when-mpol_mf_move-and-mpol_mf_strict-were-specified.patch
* 
mm-mempolicy-make-the-behavior-consistent-when-mpol_mf_move-and-mpol_mf_strict-were-specified-v4.patch
* mm-mempolicy-handle-vma-with-unmovable-pages-mapped-correctly-in-mbind.patch
* 
mm-mempolicy-handle-vma-with-unmovable-pages-mapped-correctly-in-mbind-v4.patch
* mm-z3foldc-fix-z3fold_destroy_pool-ordering.patch
* mm-z3foldc-fix-z3fold_destroy_pool-race-condition.patch
* mm-memcontrol-fix-use-after-free-in-mem_cgroup_iter.patch
* mm-vmallocc-fix-percpu-free-vm-area-search-criteria.patch
* kbuild-clean-compressed-initramfs-image.patch
* ocfs2-use-jbd2_inode-dirty-range-scoping.patch
* jbd2-remove-jbd2_journal_inode_add_.patch
* 
fs-ocfs2-fix-possible-null-pointer-dereferences-in-ocfs2_xa_prepare_entry.patch
* 
fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_write_end_nolock.patch
* 
fs-ocfs2-fix-a-possible-null-pointer-dereference-in-ocfs2_info_scan_inode_alloc.patch
* ocfs2-clear-zero-in-unaligned-direct-io.patch
* ocfs2-clear-zero-in-unaligned-direct-io-checkpatch-fixes.patch
* ocfs2-wait-for-recovering-done-after-direct-unlock-request.patch
* ocfs2-checkpoint-appending-truncate-log-transaction-before-flushing.patch
* ramfs-support-o_tmpfile.patch
  mm.patch
* mm-slab-extend-slab-shrink-to-shrink-all-memcg-caches.patch
* mm-slab-move-memcg_cache_params-structure-to-mm-slabh.patch
* kmemleak-increase-debug_kmemleak_early_log_size-default-to-16k.patch
* mm-kmemleak-use-mempool-allocations-for-kmemleak-objects.patch
* memremap-move-from-kernel-to-mm.patch
* mm-page_poison-fix-a-typo-in-a-comment.patch
* 

Re: [PATCH] ext4: Fix deadlock on page reclaim

[Damien Le Moal]

Dave,

On 2019/07/31 8:48, Dave Chinner wrote:
> On Tue, Jul 30, 2019 at 02:06:33AM +, Damien Le Moal wrote:
>> If we had a pread_nofs()/pwrite_nofs(), that would work. Or we could define a
>> RWF_NORECLAIM flag for pwritev2()/preadv2(). This last one could actually be 
>> the
>> cleanest approach.
> 
> Clean, yes, but I'm not sure we want to expose kernel memory reclaim
> capabilities to userspace... It would be misleading, too, because we
> still want to allow reclaim to occur, just not have reclaim recurse
> into other filesystems

When I wrote RWF_NORECLAIM, I was really thinking of RWF_NOFSRECLAIM. So
suppressing direct reclaim recursing into another FS rather than completely
disabling reclaim. Sorry for the confusion.

Would this be better ? This is still application controlled, so debatable if
control should be given. Most likely this would need to be limited to CAP_SYS
capable user processes (e.g. root processes).

I still need to check on FUSE if anything at all along these lines exists there.
I will dig.

Best regards.

-- 
Damien Le Moal
Western Digital Research

Re: media: mtk-vcodec: Handle H264 error bitstreams

[gtk_ruiwang]

Dear Mauro,

patch v2 uploaded.

Thanks,
Best Regards

On Tue, 2019-07-30 at 13:15 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 26 Jul 2019 16:54:33 +0800
>  escreveu:
> 
> > From: gtk_ruiwang 
> 
> ...
> 
> > Signed-off-by: gtk_ruiwang 
> 
> Please use your real name on your SOB and at the From: line.
> 
> Thanks,
> Mauro

Re: [PATCH v8 00/14] Rockchip ISP1 Driver

[Hans Verkuil]

On 7/31/19 6:29 AM, Hans Verkuil wrote:
> On 7/31/19 2:08 AM, Helen Koike wrote:
>>
>>
>> On 7/30/19 5:50 PM, Helen Koike wrote:
>>>
>>>
>>> On 7/30/19 5:15 PM, Hans Verkuil wrote:
 On 7/30/19 8:42 PM, Helen Koike wrote:
> Hello,
>
> I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
> rk3399 SoC.
>
> I didn't change much from the last version, just applying the
> suggestions made in the previous one.
>
> This patchset is also available at:
> https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v8
>
> Libcamera patched to work with this version:
> https://gitlab.collabora.com/koike/libcamera
> (also sent to the mailing list)
>
> I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
> Scarlet Chromebook.
>
> Known issues (same as in v7):
> -
> - Reloading the module doesn't work (there is some missing cleanup when
> unloading)
> - When capturing in bayer format, changing the size doesn't seem to
> affect the image.
> - crop needs more tests
> - v4l2-compliance error:
> fail: v4l2-test-controls.cpp(824): subscribe event for control 
> 'Image Processing Controls' failed
> test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL

 Can you mail me the full v4l2-compliance output?
>>>
>>> Sure, please check here: http://ix.io/1Q5u
>>> I updated v4l-utils with the latest version and I re-ran 
>>> bootstrap/configure/make,
>>> but for some reason the hash from the link above is not the latest commit, 
>>> probably some
>>> old configuration somewhere. I'll resend this log as soon as I get 
>>> v4l2-compliance
>>> properly updated.
>>
>> Please see the output of v4l2-compliance here with an updated v4l-utils: 
>> http://ix.io/1Q6A
> 
> So this FAIL is for /dev/v4l-subdev0 (rkisp1-isp-subdev).
> 
> What is weird that this subdev does not appear to have controls at all.
> 
> What is the output of 'v4l2-ctl -d /dev/v4l-subdev0 -l'? And if it lists
> controls, then why?
> 
> If you run 'v4l2-compliance -u /dev/v4l-subdev0', do you get a fail as
> well?

I see the same issue with v4l-subdev1, but I see no "Media Driver Info"
in the v4l2-compliance output for that subdev. That's strange. It would
be good to know why that's happening.

Regards,

Hans

> 
> BTW, note that struct rkisp1_isp_subdev has a ctrl_handler field that
> isn't used at all.
> 
> Regards,
> 
>   Hans
> 

Re: [PATCH] MIPS: Ingenic: Fix bugs when detecting X1000's parameters.

[Zhou Yanjie]

Hi Paul,
On 2019年07月31日 02:02, Paul Cercueil wrote:

Hi Zhou,



Le mar. 30 juil. 2019 à 10:55, Zhou Yanjie  a 
écrit :

1.fix bugs when detecting L2 cache sets value.
2.fix bugs when detecting L2 cache ways value.
3.fix bugs when calculate bogoMips and loops_per_jiffy.

Signed-off-by: Zhou Yanjie 
---
 arch/mips/kernel/cpu-probe.c |  7 ++-
 arch/mips/mm/sc-mips.c   | 18 +++---
 2 files changed, 21 insertions(+), 4 deletions(-)

diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c
index eb527a1..a914435 100644
--- a/arch/mips/kernel/cpu-probe.c
+++ b/arch/mips/kernel/cpu-probe.c
@@ -1960,11 +1960,16 @@ static inline void cpu_probe_ingenic(struct 
cpuinfo_mips *c, unsigned int cpu)

 c->options &= ~MIPS_CPU_COUNTER;
 BUG_ON(!__builtin_constant_p(cpu_has_counter) || cpu_has_counter);
 switch (c->processor_id & PRID_IMP_MASK) {
-case PRID_IMP_XBURST:
+case PRID_IMP_XBURST: {
+unsigned int config7;
 c->cputype = CPU_XBURST;
 c->writecombine = _CACHE_UNCACHED_ACCELERATED;
 __cpu_name[cpu] = "Ingenic XBurst";
+config7 = read_c0_config7();
+config7 |= (1 << 4);
+write_c0_config7(config7);


If you add __BUILD_SET_C0(config7) in arch/mips/include/asm/mipsregs.h
(search for this macro) then you can call directly 
set_c0_config7(BIT(4)).


It's preferred to use the BIT(x) macro instead of the (1 << x) construct.

Thanks for your suggestion, I have used set_c0_config7(BIT(4)) instead
of the (1 << x) construct in v2.

Finally, what does that bit do? I can't find it any documentation about
it. Please add a comment describing what it does.

According to Ingenic's explanation, in the XBurst architecture this bit is
used to control a low-power mode, which is intended to allow the CPU
to further reduce power consumption, but due to some bugs, it is easy
to cause errors in the calculation of bogomips and loops_per_jiffy, So
Ingenic's suggestion is to set this bit to turn it off.



 break;
+}
 default:
 panic("Unknown Ingenic Processor ID!");
 break;
diff --git a/arch/mips/mm/sc-mips.c b/arch/mips/mm/sc-mips.c
index 9385ddb..ed953d4 100644
--- a/arch/mips/mm/sc-mips.c
+++ b/arch/mips/mm/sc-mips.c
@@ -215,6 +215,14 @@ static inline int __init mips_sc_probe(void)
 else
 return 0;

+/*
+ * According to config2 it would be 512-sets, but that is 
contradicted

+ * by all documentation.
+ */
+if (current_cpu_type() == CPU_XBURST &&
+mips_machtype == MACH_INGENIC_X1000)
+c->scache.sets = 256;
+
 tmp = (config2 >> 0) & 0x0f;
 if (tmp <= 7)
 c->scache.ways = tmp + 1;
@@ -225,9 +233,13 @@ static inline int __init mips_sc_probe(void)
  * According to config2 it would be 5-ways, but that is 
contradicted

  * by all documentation.
  */
-if (current_cpu_type() == CPU_XBURST &&
-mips_machtype == MACH_INGENIC_JZ4770)
-c->scache.ways = 4;
+if (current_cpu_type() == CPU_XBURST) {
+switch (mips_machtype) {
+case MACH_INGENIC_JZ4770:
+case MACH_INGENIC_X1000:
+c->scache.ways = 4;
+}
+}

 c->scache.waysize = c->scache.sets * c->scache.linesz;
 c->scache.waybit = __ffs(c->scache.waysize);
--
2.7.4

Re: [PATCH v8 00/14] Rockchip ISP1 Driver

[Hans Verkuil]

On 7/31/19 2:08 AM, Helen Koike wrote:
> 
> 
> On 7/30/19 5:50 PM, Helen Koike wrote:
>>
>>
>> On 7/30/19 5:15 PM, Hans Verkuil wrote:
>>> On 7/30/19 8:42 PM, Helen Koike wrote:
 Hello,

 I'm re-sending a new version of ISP(Camera) v4l2 driver for rockchip
 rk3399 SoC.

 I didn't change much from the last version, just applying the
 suggestions made in the previous one.

 This patchset is also available at:
 https://gitlab.collabora.com/koike/linux/tree/rockchip/isp/v8

 Libcamera patched to work with this version:
 https://gitlab.collabora.com/koike/libcamera
 (also sent to the mailing list)

 I tested on the rockpi 4 with a rpi v1.3 sensor and also with the
 Scarlet Chromebook.

 Known issues (same as in v7):
 -
 - Reloading the module doesn't work (there is some missing cleanup when
 unloading)
 - When capturing in bayer format, changing the size doesn't seem to
 affect the image.
 - crop needs more tests
 - v4l2-compliance error:
 fail: v4l2-test-controls.cpp(824): subscribe event for control 
 'Image Processing Controls' failed
 test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: FAIL
>>>
>>> Can you mail me the full v4l2-compliance output?
>>
>> Sure, please check here: http://ix.io/1Q5u
>> I updated v4l-utils with the latest version and I re-ran 
>> bootstrap/configure/make,
>> but for some reason the hash from the link above is not the latest commit, 
>> probably some
>> old configuration somewhere. I'll resend this log as soon as I get 
>> v4l2-compliance
>> properly updated.
> 
> Please see the output of v4l2-compliance here with an updated v4l-utils: 
> http://ix.io/1Q6A

So this FAIL is for /dev/v4l-subdev0 (rkisp1-isp-subdev).

What is weird that this subdev does not appear to have controls at all.

What is the output of 'v4l2-ctl -d /dev/v4l-subdev0 -l'? And if it lists
controls, then why?

If you run 'v4l2-compliance -u /dev/v4l-subdev0', do you get a fail as
well?

BTW, note that struct rkisp1_isp_subdev has a ctrl_handler field that
isn't used at all.

Regards,

Hans

Re: [PATCH 4/4] net: dsa: mv88e6xxx: add PTP support for MV88E6250 family

[Richard Cochran]

On Tue, Jul 30, 2019 at 11:46:51PM +0300, Vladimir Oltean wrote:

> Technically it is not "not true".

[Sigh]  The statement was:

The adjfine API clamps ppb between [-32,768,000, 32,768,000]

The adjfine API does NOT clamp to that range.  That statement is
simply false.

> And what is the reason for the neg_adj thing? Can you give an example
> of when does the "normal way" of doing signed arithmetics not work?

The detail from years ago escape me ATM, but I needed to use div_u64.
Maybe div_s64 was broken.

But that is not the point.  Changing the adjfine() logic for this
driver is out of scope for this series.  If someone thinks the logic
needs changing, then that must carefully explained and justified in
the changelog of a patch implementing that _one_ change.

Thanks,
Richard

[v2] media: mtk-vcodec: Handle H264 error bitstreams

[gtk_ruiwang]

From: Rui Wang 

Error h264 bitstreams which picture info are out range of
decoder hardware specification, and no nal start code at the
beginning of the buffer, stop decoding and exit.

Signed-off-by: Rui Wang 
---
Change note:
Updata commint message with Mauro's comment: use real name on SOB and From.
---
 .../platform/mtk-vcodec/vdec/vdec_h264_if.c  | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c 
b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
index c5f8f1fca44c..49aa85a9bb5a 100644
--- a/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
+++ b/drivers/media/platform/mtk-vcodec/vdec/vdec_h264_if.c
@@ -29,6 +29,9 @@
 #define H264_MAX_FB_NUM17
 #define HDR_PARSING_BUF_SZ 1024
 
+#define DEC_ERR_RET(ret)   ((ret) >> 16)
+#define H264_ERR_NOT_VALID 3
+
 /**
  * struct h264_fb - h264 decode frame buffer information
  * @vdec_fb_va  : virtual address of struct vdec_fb
@@ -357,8 +360,11 @@ static int vdec_h264_decode(void *h_vdec, struct 
mtk_vcodec_mem *bs,
buf = (unsigned char *)bs->va;
buf_sz = bs->size;
nal_start_idx = find_start_code(buf, buf_sz);
-   if (nal_start_idx < 0)
+   if (nal_start_idx < 0) {
+   mtk_vcodec_err(inst, "invalid nal start code");
+   err = -EIO;
goto err_free_fb_out;
+   }
 
nal_start = buf[nal_start_idx];
nal_type = NAL_TYPE(buf[nal_start_idx]);
@@ -382,8 +388,14 @@ static int vdec_h264_decode(void *h_vdec, struct 
mtk_vcodec_mem *bs,
data[0] = buf_sz;
data[1] = nal_start;
err = vpu_dec_start(vpu, data, 2);
-   if (err)
+   if (err) {
+   if (err > 0 && (DEC_ERR_RET(err) == H264_ERR_NOT_VALID)) {
+   mtk_vcodec_err(inst, "- error bitstream - err = %d -",
+  err);
+   err = -EIO;
+   }
goto err_free_fb_out;
+   }
 
*res_chg = inst->vsi->dec.resolution_changed;
if (*res_chg) {
-- 
2.18.0

Re: [PATCH] IB/core: Add mitigation for Spectre V1

[Ira Weiny]

On Tue, Jul 30, 2019 at 06:52:12PM -0500, Gustavo A. R. Silva wrote:
> 
> 
> On 7/30/19 3:24 PM, Tony Luck wrote:
> > Some processors may mispredict an array bounds check and
> > speculatively access memory that they should not. With
> > a user supplied array index we like to play things safe
> > by masking the value with the array size before it is
> > used as an index.
> > 
> > Signed-off-by: Tony Luck 
> > ---
> > 
> > [I don't have h/w, so just compile tested]
> > 
> >  drivers/infiniband/core/user_mad.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/infiniband/core/user_mad.c 
> > b/drivers/infiniband/core/user_mad.c
> > index 9f8a48016b41..fdce254e4f65 100644
> > --- a/drivers/infiniband/core/user_mad.c
> > +++ b/drivers/infiniband/core/user_mad.c
> > @@ -49,6 +49,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  
> > @@ -888,6 +889,7 @@ static int ib_umad_unreg_agent(struct ib_umad_file 
> > *file, u32 __user *arg)
> > mutex_lock(>port->file_mutex);
> > mutex_lock(>mutex);
> >  
> > +   id = array_index_nospec(id, IB_UMAD_MAX_AGENTS);
> 
> This is wrong. This prevents the below condition id >= IB_UMAD_MAX_AGENTS
> from ever being true. And I don't think this is what you want.

Ah Yea...  FWIW this would probably never be hit.

Tony; split the check?

if (id >= IB_UMAD_MAX_AGENTS) {
ret = -EINVAL;
goto out;
}

id = array_index_nospec(id, IB_UMAD_MAX_AGENTS);

if (!__get_agent(file, id)) {
ret = -EINVAL;
goto out;
}

Ira

> 
> > if (id >= IB_UMAD_MAX_AGENTS || !__get_agent(file, id)) {
> > ret = -EINVAL;
> > goto out;
> > 
> 
> --
> Gustavo

Re: [PATCH v2 2/5] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs

[Paul Walmsley]

On Tue, 30 Jul 2019, Atish Patra wrote:

> From: Anup Patel 
> 
> This patch adds riscv_isa integer to represent ISA features common
> across all CPUs. The riscv_isa is not same as elf_hwcap because
> elf_hwcap will only have ISA features relevant for user-space apps
> whereas riscv_isa will have ISA features relevant to both kernel
> and user-space apps.
> 
> One of the use case is KVM hypervisor where riscv_isa will be used
> to do following operations:
> 
> 1. Check whether hypervisor extension is available
> 2. Find ISA features that need to be virtualized (e.g. floating
>point support, vector extension, etc.)
> 
> Signed-off-by: Anup Patel 
> Signed-off-by: Atish Patra 
> ---
>  arch/riscv/include/asm/hwcap.h | 25 +
>  arch/riscv/kernel/cpufeature.c | 41 +++---
>  2 files changed, 63 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 7ecb7c6a57b1..e069f60ad5d2 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -22,5 +22,30 @@ enum {
>  };
>  
>  extern unsigned long elf_hwcap;
> +
> +#define RISCV_ISA_EXT_A  (1UL << ('A' - 'A'))

Are these uppercase variants still needed if we define the ISA string to 
be all lowercase, per our recent discussion?

> +#define RISCV_ISA_EXT_a  RISCV_ISA_EXT_A
> +#define RISCV_ISA_EXT_C  (1UL << ('C' - 'A'))
> +#define RISCV_ISA_EXT_c  RISCV_ISA_EXT_C
> +#define RISCV_ISA_EXT_D  (1UL << ('D' - 'A'))
> +#define RISCV_ISA_EXT_d  RISCV_ISA_EXT_D
> +#define RISCV_ISA_EXT_F  (1UL << ('F' - 'A'))
> +#define RISCV_ISA_EXT_f  RISCV_ISA_EXT_F
> +#define RISCV_ISA_EXT_H  (1UL << ('H' - 'A'))
> +#define RISCV_ISA_EXT_h  RISCV_ISA_EXT_H
> +#define RISCV_ISA_EXT_I  (1UL << ('I' - 'A'))
> +#define RISCV_ISA_EXT_i  RISCV_ISA_EXT_I
> +#define RISCV_ISA_EXT_M  (1UL << ('M' - 'A'))
> +#define RISCV_ISA_EXT_m  RISCV_ISA_EXT_M
> +#define RISCV_ISA_EXT_S  (1UL << ('S' - 'A'))
> +#define RISCV_ISA_EXT_s  RISCV_ISA_EXT_S
> +#define RISCV_ISA_EXT_U  (1UL << ('U' - 'A'))
> +#define RISCV_ISA_EXT_u  RISCV_ISA_EXT_U
> +
> +extern unsigned long riscv_isa;
> +
> +#define riscv_isa_extension_available(ext_char)  \
> + (riscv_isa & RISCV_ISA_EXT_##ext_char)
> +
>  #endif
>  #endif
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index b1ade9a49347..177529d48d87 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c

[ ... ]

> @@ -43,8 +49,22 @@ void riscv_fill_hwcap(void)
>   continue;
>   }
>  
> - for (i = 0; i < strlen(isa); ++i)
> + i = 0;
> + isa_len = strlen(isa);
> +#if defined(CONFIG_32BIT)
> + if (strncasecmp(isa, "rv32", 4) != 0)

strcmp()?

> + i += 4;
> +#elif defined(CONFIG_64BIT)
> + if (strncasecmp(isa, "rv64", 4) != 0)

And again here?

> + i += 4;
> +#endif
> + for (; i < isa_len; ++i) {
>   this_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
> + if ('a' <= isa[i] && isa[i] <= 'z')
> + this_isa |= (1UL << (isa[i] - 'a'));
> + if ('A' <= isa[i] && isa[i] <= 'Z')
> + this_isa |= (1UL << (isa[i] - 'A'));

Are these uppercase variants still needed?


- Paul

[PATCH] Introducing the mask_cstate to disable specific c-states during bootup

[Chen Yu]

There is request to disable specific c-states during bootup for
debug purpose. For example, deeper c-states except C1,C1E,C10
are disabled during bootup otherwise it might not boot up well
due to incorrect setting in FW.

For example, intel_idle.mask_cstate=0x3c, would disable cstate
2,3,4,5 in the table
(1<<2) | (1<<3) | (1<<4) | (1<<5)
which is C6,C7s,C8,C9 on Broxton.
This could have it come up as present, but with c-states disabled,
so user can enable those c-states later to test.

Cc: Len Brown 
Cc: "Wysocki, Rafael J" 
Cc: Rui Zhang 
Cc: David Box 
Cc: "Tan, Raymond" 
Signed-off-by: Chen Yu 
---
 .../admin-guide/kernel-parameters.txt |  7 
 drivers/idle/intel_idle.c | 36 +++
 2 files changed, 43 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 7ccd158b3894..93a326c42877 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1733,6 +1733,13 @@
provided by tboot because it makes the system
vulnerable to DMA attacks.
 
+   intel_idle.mask_cstate= [HW,X86]
+   Mask of C-states to be disabled during bootup. For
+   example, mask_cstate=0x3c, would disable cstate 2,3,4,5
+   in the table
+   (1<<2) | (1<<3) | (1<<4) | (1<<5)
+   which is C6,C7s,C8,C9 on Broxton.
+
intel_idle.max_cstate=  [KNL,HW,ACPI,X86]
0   disables intel_idle and fall back on acpi_idle.
1 to 9  specify maximum depth of C-state.
diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
index fa5ff77b8fe4..ed3233864b69 100644
--- a/drivers/idle/intel_idle.c
+++ b/drivers/idle/intel_idle.c
@@ -63,6 +63,8 @@ static struct cpuidle_driver intel_idle_driver = {
 /* intel_idle.max_cstate=0 disables driver */
 static int max_cstate = CPUIDLE_STATE_MAX - 1;
 
+static unsigned int mask_cstate;
+
 static unsigned int mwait_substates;
 
 #define LAPIC_TIMER_ALWAYS_RELIABLE 0x
@@ -1354,6 +1356,12 @@ static void __init intel_idle_cpuidle_driver_init(void)
if (num_substates == 0)
continue;
 
+   if ((1UL<= CPUIDLE_STATE_MAX) {
+   ret = -EINVAL;
+   goto exit_mask;
+   }
+
+   mask_cstate = new_mask_cstate;
+   smp_mb();
+
+exit_mask:
+   return ret;
+}
+
+static const struct kernel_param_ops mask_cstate_ops = {
+   .set = mask_cstate_set,
+   .get = param_get_int,
+};
+module_param_cb(mask_cstate, _cstate_ops, _cstate, 0644);
-- 
2.17.1

Re: [RFC PATCH] ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up

[Luis Araneda]

Hi Russell,

Thanks for reviewing.

On Tue, Jul 30, 2019 at 6:47 AM Russell King - ARM Linux admin
 wrote:
>
> On Tue, Jul 30, 2019 at 12:43:26AM -0400, Luis Araneda wrote:
> > This fixes a kernel panic (read overflow) on memcpy when
> > FORTIFY_SOURCE is enabled.
[...]
>
> I'm not convinced that this is correct.  It looks like
> zynq_secondary_trampoline could be either ARM or Thumb code - there is
> no .arm directive before it.  If it's ARM code, then this is fine.  If
> Thumb code, then zynq_secondary_trampoline will be offset by one, and
> we will miss copying the first byte of code.

You're right, I tested what happens if the zynq_secondary_trampoline
is ARM or Thumb by editing the file where it's defined, headsmp.S

When the .arm directive is used, the CPU is brought-up correctly,
but if I use .thumb, I get the following message (no panic):
> CPU1: failed to come online

This seems unrelated to solving the panic, as the message
even appears with memcpy and FORTIFY_SOURCE disabled.

I could add the .arm directive to headsmp.S
Is that your expected solution?
Should that change be on a separate commit?

I'd like to know Michal's opinion, as he wrote the code.

Re: [PATCH v1 0/2] virtio-mmio: support multiple interrupt vectors

[李菲]

Hi Sergio,

Considering your implementing virtio-mmio v2 in Qemu, please help to give some
suggestions on this patch series. Thanks :)

For web, this link:
https://www.spinics.net/lists/kernel/msg3195667.html may help.

Have a nice day
Fei

On Fri, Jul 19, 2019 at 9:31 PM Fei Li  wrote:
>
> Hi,
>
> This patch series implements multiple interrupt vectors support for
> virtio-mmio device. This is especially useful for multiqueue vhost-net
> device when using firecracker micro-vms as the guest.
>
> Test result:
> With 8 vcpus & 8 net queues set, one vhost-net device with 8 irqs can
> receive 9 times more pps comparing with only one irq:
> - 564830.38 rxpck/s for 8 irqs on
> - 67665.06 rxpck/s for 1 irq on
>
> Please help to review, thanks!
>
> Have a nice day
> Fei
>
>
> Fam Zheng (1):
>   virtio-mmio: Process vrings more proactively
>
> Fei Li (1):
>   virtio-mmio: support multiple interrupt vectors
>
>  drivers/virtio/virtio_mmio.c | 238 
> +++
>  1 file changed, 196 insertions(+), 42 deletions(-)
>
> --
> 2.11.0
>

Re: [External Email] Re: [PATCH v1 0/2] virtio-mmio: support multiple interrupt vectors

[李菲]

On Wed, Jul 31, 2019 at 4:26 AM Michael S. Tsirkin  wrote:
>
> On Mon, Jul 22, 2019 at 09:43:18PM +0800, 李菲 wrote:
> > On Mon, Jul 22, 2019 at 4:39 PM Michael S. Tsirkin  wrote:
> > >
> > > On Mon, Jul 22, 2019 at 11:22:02AM +0800, 李菲 wrote:
> > > > On Fri, Jul 19, 2019 at 11:14 PM Michael S. Tsirkin  
> > > > wrote:
> > > > >
> > > > > On Fri, Jul 19, 2019 at 09:31:33PM +0800, Fei Li wrote:
> > > > > > Hi,
> > > > > >
> > > > > > This patch series implements multiple interrupt vectors support for
> > > > > > virtio-mmio device. This is especially useful for multiqueue 
> > > > > > vhost-net
> > > > > > device when using firecracker micro-vms as the guest.
> > > > > >
> > > > > > Test result:
> > > > > > With 8 vcpus & 8 net queues set, one vhost-net device with 8 irqs 
> > > > > > can
> > > > > > receive 9 times more pps comparing with only one irq:
> > > > > > - 564830.38 rxpck/s for 8 irqs on
> > > > > > - 67665.06 rxpck/s for 1 irq on
> > > > > >
> > > > > > Please help to review, thanks!
> > > > > >
> > > > > > Have a nice day
> > > > > > Fei
> > > > >
> > > > >
> > > > > Interesting. The spec says though:
> > > > >
> > > > > 4.2.3.4
> > > > > Notifications From The Device
> > > > > The memory mapped virtio device is using a single, dedicated 
> > > > > interrupt signal, which is asserted when at
> > > > > least one of the bits described in the description of 
> > > > > InterruptStatus is set. This is how the device sends a
> > > > > used buffer notification or a configuration change 
> > > > > notification to the device.
> > > > >
> > > > Yes, the spec needs to be updated if we want to use mult-irqs.
> > > > >
> > > > > So I'm guessing we need to change the host/guest interface?
> > > > Just to confirm, does the "the host/guest interface" you mentioned mean 
> > > > how to
> > > > pass the irq information from the user space tool to guest kernel?
> > > > In this patch, we do this by passing the [irq_start, irq_end]
> > > > interface via setting guest
> > > > kernel command line, that is done in vm_cmdline_set().
> > > > Also there is another way to do this: add two new registers describing 
> > > > irq info
> > > > (irq_start & irq_end OR irq_start & irq_numbers) to the virtio config 
> > > > space.
> > > >
> > > > Which one do you prefer?
> > >
> > > I'm not sure - so far irq was passed on the command line, right?
> > Yes.
> > >
> > > The first step in implementing any spec change would be to update qemu
> > > code to virtio 1. Which is not a huge project but so far no one
> > > bothered.
> > Emm, actually I only did the test with using firecracker to start a
> > micro-vm, but without qemu.
> > To be honest, the reason why implementing multi-irq on virtio-mmio is
> > mainly because the
> > current firecracker using virtio-mmio device and it has no pci thing,
> > thus no msi/msix to
> > handle the interruptions.
> > On the other hand, considering pci is well supported in qemu, I am
> > wondering whether we
> > still need this. If needed, we would like to do this. :)
> >
> > Have a nice day, thanks
> > Fei
>
>
> Sergio Lopez is now working on updating mmio to v1 support in qemu.
> Maybe get in touch with him on how he looks at this extension.
Thanks for the info! :)

Hi Sergio Lopez,
I saw your [virtio-mmio: modern (v2)] patch series in Qemu mailing
list, thanks for moving this on.
And long Story Short, these two kernel patches is to add the multi-irq
support for virtio-mmio driver.
As this involves the spec change and you are now implementing
virtio-mmio v2, could you help to
give some suggestions on this extension?
I will cc you the original patch soon, thanks.

> Not asking you to work on qemu, but it makes sense
> to get an ack for guest bits from another popular hypervisor.
I agree, absolutely right. And I once work on Qemu development, hope
the combined
background could help to move this multi-irq feature forward. :)


Have a nice day, many thanks
Fei
>
>
> > >
> > >
> > > > > If true pls cc virtio-dev.
> > > > Sure.
> > > > >
> > > > > Also, do we need to update dt bindings documentation?
> > > > You mean the following doc? Sure. :)
> > > > https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/virtio/mmio.txt
> > > >
> > > > Thanks for the review!
> > > >
> > > > Have a nice day
> > > > Fei
> > > >
> > > >
> > > > >
> > > > > >
> > > > > > Fam Zheng (1):
> > > > > >   virtio-mmio: Process vrings more proactively
> > > > > >
> > > > > > Fei Li (1):
> > > > > >   virtio-mmio: support multiple interrupt vectors
> > > > > >
> > > > > >  drivers/virtio/virtio_mmio.c | 238 
> > > > > > +++
> > > > > >  1 file changed, 196 insertions(+), 42 deletions(-)
> > > > > >
> > > > > > --
> > > > > > 2.11.0

Dear Friend,

[Aisha Gaddafi]

Dear Friend,

I came across your e-mail contact prior a private search while in need of 
your assistance. My name is Aisha  Gaddafi a single Mother and a Widow with 
three Children. I am the only biological Daughter of late Libyan President 
(Late Colonel Muammar Gaddafi).

I have investment funds worth Twenty Seven Million Five Hundred Thousand 
United State Dollar ($27.500.000.00 ) and i need a trusted investment 
Manager/Partner because of my current refugee status, however, I am 
interested in you for investment project assistance in your country, may be 
from there, we can build business relationship in the nearest future.

I am willing to negotiate investment/business profit sharing ratio with you 
base on the future investment earning profits.

If you are willing to handle this project on my behalf kindly reply urgent 
to enable me provide you more information about the investment funds.

Your Urgent Reply Will Be Appreciated.

Best Regards
Mrs Aisha Gaddafi
(gaisha...@gmail.com)

Re: [PATCH v4 03/10] livepatch: Add klp-convert tool

[Masahiro Yamada]

On Wed, Jul 31, 2019 at 11:50 AM Masahiro Yamada
 wrote:
>
> On Thu, May 9, 2019 at 11:39 PM Joe Lawrence  wrote:
> >
> > From: Josh Poimboeuf 
> >
> > Livepatches may use symbols which are not contained in its own scope,
> > and, because of that, may end up compiled with relocations that will
> > only be resolved during module load. Yet, when the referenced symbols
> > are not exported, solving this relocation requires information on the
> > object that holds the symbol (either vmlinux or modules) and its
> > position inside the object, as an object may contain multiple symbols
> > with the same name. Providing such information must be done
> > accordingly to what is specified in
> > Documentation/livepatch/module-elf-format.txt.
> >
> > Currently, there is no trivial way to embed the required information
> > as requested in the final livepatch elf object. klp-convert solves
> > this problem in two different forms: (i) by relying on Symbols.list,
> > which is built during kernel compilation, to automatically infer the
> > relocation targeted symbol, and, when such inference is not possible
> > (ii) by using annotations in the elf object to convert the relocation
> > accordingly to the specification, enabling it to be handled by the
> > livepatch loader.
> >
> > Given the above, create scripts/livepatch to hold tools developed for
> > livepatches and add source files for klp-convert there.
> >
> > The core file of klp-convert is scripts/livepatch/klp-convert.c, which
> > implements the heuristics used to solve the relocations and the
> > conversion of unresolved symbols into the expected format, as defined
> > in [1].
> >
> > klp-convert receives as arguments the Symbols.list file, an input
> > livepatch module to be converted and the output name for the converted
> > livepatch. When it starts running, klp-convert parses Symbols.list and
> > builds two internal lists of symbols, one containing the exported and
> > another containing the non-exported symbols. Then, by parsing the rela
> > sections in the elf object, klp-convert identifies which symbols must
> > be converted, which are those unresolved and that do not have a
> > corresponding exported symbol, and attempts to convert them
> > accordingly to the specification.
> >
> > By using Symbols.list, klp-convert identifies which symbols have names
> > that only appear in a single kernel object, thus being capable of
> > resolving these cases without the intervention of the developer. When
> > various homonymous symbols exist through kernel objects, it is not
> > possible to infer the right one, thus klp-convert falls back into
> > using developer annotations. If these were not provided, then the tool
> > will print a list with all acceptable targets for the symbol being
> > processed.
> >
> > Annotations in the context of klp-convert are accessible as struct
> > klp_module_reloc entries in sections named
> > .klp.module_relocs.. These entries are pairs of symbol
> > references and positions which are to be resolved against definitions
> > in .
> >
> > Define the structure klp_module_reloc in
> > include/linux/uapi/livepatch.h allowing developers to annotate the
> > livepatch source code with it.
> >
> > klp-convert relies on libelf and on a list implementation. Add files
> > scripts/livepatch/elf.c and scripts/livepatch/elf.h, which are a
> > libelf interfacing layer and scripts/livepatch/list.h, which is a
> > list implementation.
> >
> > Update Makefiles to correctly support the compilation of the new tool,
> > update MAINTAINERS file and add a .gitignore file.
> >
> > [1] - Documentation/livepatch/module-elf-format.txt
> >
> > Signed-off-by: Josh Poimboeuf 
> > Signed-off-by: Konstantin Khlebnikov 
> > Signed-off-by: Joao Moreira 
> > Signed-off-by: Joe Lawrence 
> > ---
> >  MAINTAINERS |   1 +
> >  include/uapi/linux/livepatch.h  |   5 +
> >  scripts/Makefile|   1 +
> >  scripts/livepatch/.gitignore|   1 +
> >  scripts/livepatch/Makefile  |   7 +
> >  scripts/livepatch/elf.c | 753 
> >  scripts/livepatch/elf.h |  73 
> >  scripts/livepatch/klp-convert.c | 713 ++
> >  scripts/livepatch/klp-convert.h |  39 ++
> >  scripts/livepatch/list.h| 391 +
> >  10 files changed, 1984 insertions(+)
> >  create mode 100644 scripts/livepatch/.gitignore
> >  create mode 100644 scripts/livepatch/Makefile
> >  create mode 100644 scripts/livepatch/elf.c
> >  create mode 100644 scripts/livepatch/elf.h
> >  create mode 100644 scripts/livepatch/klp-convert.c
> >  create mode 100644 scripts/livepatch/klp-convert.h
> >  create mode 100644 scripts/livepatch/list.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 52842fa37261..c1587e1cc385 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -9022,6 +9022,7 @@ F:arch/x86/kernel/livepatch.c
> >  F: Documentation/livepatch/
> >  F: 

Re: [RFC] net: phy: read link status twice when phy_check_link_status()

[liuyonglong]

On 2019/7/31 3:04, Heiner Kallweit wrote:
> On 30.07.2019 08:35, liuyonglong wrote:
>> :/sys/kernel/debug/tracing$ cat trace
>> # tracer: nop
>> #
>> # entries-in-buffer/entries-written: 45/45   #P:128
>> #
>> #  _-=> irqs-off
>> # / _=> need-resched
>> #| / _---=> hardirq/softirq
>> #|| / _--=> preempt-depth
>> #||| / delay
>> #   TASK-PID   CPU#  TIMESTAMP  FUNCTION
>> #  | |   |      | |
>> kworker/64:2-1028  [064]    172.295687: mdio_access: 
>> mii-:bd:00.0 read  phy:0x01 reg:0x02 val:0x001c
>> kworker/64:2-1028  [064]    172.295726: mdio_access: 
>> mii-:bd:00.0 read  phy:0x01 reg:0x03 val:0xc916
>> kworker/64:2-1028  [064]    172.296902: mdio_access: 
>> mii-:bd:00.0 read  phy:0x01 reg:0x01 val:0x79ad
>> kworker/64:2-1028  [064]    172.296938: mdio_access: 
>> mii-:bd:00.0 read  phy:0x01 reg:0x0f val:0x2000
>> kworker/64:2-1028  [064]    172.321213: mdio_access: 
>> mii-:bd:00.0 read  phy:0x01 reg:0x00 val:0x1040
>> kworker/64:2-1028  [064]    172.343209: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x02 val:0x001c
>> kworker/64:2-1028  [064]    172.343245: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x03 val:0xc916
>> kworker/64:2-1028  [064]    172.343882: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
>> kworker/64:2-1028  [064]    172.343918: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x0f val:0x2000
>> kworker/64:2-1028  [064]    172.362658: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>> kworker/64:2-1028  [064]    172.385961: mdio_access: 
>> mii-:bd:00.2 read  phy:0x05 reg:0x02 val:0x001c
>> kworker/64:2-1028  [064]    172.385996: mdio_access: 
>> mii-:bd:00.2 read  phy:0x05 reg:0x03 val:0xc916
>> kworker/64:2-1028  [064]    172.386646: mdio_access: 
>> mii-:bd:00.2 read  phy:0x05 reg:0x01 val:0x79ad
>> kworker/64:2-1028  [064]    172.386681: mdio_access: 
>> mii-:bd:00.2 read  phy:0x05 reg:0x0f val:0x2000
>> kworker/64:2-1028  [064]    172.411286: mdio_access: 
>> mii-:bd:00.2 read  phy:0x05 reg:0x00 val:0x1040
>> kworker/64:2-1028  [064]    172.433225: mdio_access: 
>> mii-:bd:00.3 read  phy:0x07 reg:0x02 val:0x001c
>> kworker/64:2-1028  [064]    172.433260: mdio_access: 
>> mii-:bd:00.3 read  phy:0x07 reg:0x03 val:0xc916
>> kworker/64:2-1028  [064]    172.433887: mdio_access: 
>> mii-:bd:00.3 read  phy:0x07 reg:0x01 val:0x79ad
>> kworker/64:2-1028  [064]    172.433922: mdio_access: 
>> mii-:bd:00.3 read  phy:0x07 reg:0x0f val:0x2000
>> kworker/64:2-1028  [064]    172.452862: mdio_access: 
>> mii-:bd:00.3 read  phy:0x07 reg:0x00 val:0x1040
>> ifconfig-1324  [011]    177.325585: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>>   kworker/u257:0-8 [012]    177.325642: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x04 val:0x01e1
>>   kworker/u257:0-8 [012]    177.325654: mdio_access: 
>> mii-:bd:00.1 write phy:0x03 reg:0x04 val:0x05e1
>>   kworker/u257:0-8 [012]    177.325708: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x79ad
>>   kworker/u257:0-8 [012]    177.325744: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x09 val:0x0200
>>   kworker/u257:0-8 [012]    177.325779: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x00 val:0x1040
>>   kworker/u257:0-8 [012]    177.325788: mdio_access: 
>> mii-:bd:00.1 write phy:0x03 reg:0x00 val:0x1240
>>   kworker/u257:0-8 [012]    177.325843: mdio_access: 
>> mii-:bd:00.1 read  phy:0x03 reg:0x01 val:0x798d
> 
> What I think that happens here:
> Writing 0x1240 to BMCR starts aneg. When reading BMSR immediately after that 
> then the PHY seems to have cleared
> the "aneg complete" bit already, but not yet the "link up" bit. This results 
> in the false "link up" notification.
> The following patch is based on the fact that in case of enabled aneg we 
> can't have a valid link if aneg isn't
> finished. Could you please test whether this works for you?
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 6b5cb87f3..7ddd91df9 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1774,6 +1774,12 @@ int genphy_update_link(struct phy_device *phydev)
>   phydev->link = status & BMSR_LSTATUS ? 1 : 0;
>   phydev->autoneg_complete = status & BMSR_ANEGCOMPLETE ? 1 : 0;
>  
> + /* Consider the case that autoneg was started and "aneg complete"
> +  * bit has been reset, but "link up" bit not yet.
> +  */
> + if (phydev->autoneg == AUTONEG_ENABLE && 

Re: [PATCH] ARM: check stmfd instruction using right shift

[Chunyan Zhang]

On Tue, 30 Jul 2019 at 19:02, Russell King - ARM Linux admin
 wrote:
>
> On Tue, Jul 30, 2019 at 03:18:31PM +0800, Chunyan Zhang wrote:
> > Gentle ping
> >
> > probably this patch was missed or entered into spam?
>
> Please submit it to the patch system, thanks.

Ok, thanks.

>
> >
> > On Mon, 22 Jul 2019 at 15:14, Chunyan Zhang  wrote:
> > >
> > > From: Lvqiang Huang 
> > >
> > > In the commit ef41b5c92498 ("ARM: make kernel oops easier to read"),
> > > -   .word   0xe92d >> 10@ stmfd sp!, {}
> > > +   .word   0xe92d >> 11@ stmfd sp!, {}
> > > then the shift need to change to 11.
> > >
> > > Fixes: ef41b5c92498 ("ARM: make kernel oops easier to read")
> > > Signed-off-by: Lvqiang Huang 
> > > Signed-off-by: Chunyan Zhang 
> > > ---
> > >  arch/arm/lib/backtrace.S |2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm/lib/backtrace.S b/arch/arm/lib/backtrace.S
> > > index 7d7952e..926851b 100644
> > > --- a/arch/arm/lib/backtrace.S
> > > +++ b/arch/arm/lib/backtrace.S
> > > @@ -70,7 +70,7 @@ for_each_frame:   tst frame, mask @ 
> > > Check for address exceptions
> > >
> > >  1003:  ldr r2, [sv_pc, #-4]@ if stmfd sp!, {args} 
> > > exists,
> > > ldr r3, .Ldsi+4 @ adjust saved 'pc' back 
> > > one
> > > -   teq r3, r2, lsr #10 @ instruction
> > > +   teq r3, r2, lsr #11 @ instruction
> > > subne   r0, sv_pc, #4   @ allow for mov
> > > subeq   r0, sv_pc, #8   @ allow for mov + stmia
> > >
> > > --
> > > 1.7.9.5
> > >
> >
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up

[PATCH] thp: update split_huge_page_pmd() commnet

[Kefeng Wang]

According to 78ddc5347341 ("thp: rename split_huge_page_pmd() to
split_huge_pmd()"), update releated comment.

Signed-off-by: Kefeng Wang 
---
 arch/powerpc/mm/book3s64/hash_utils.c | 2 +-
 include/asm-generic/pgtable.h | 5 ++---
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/mm/book3s64/hash_utils.c 
b/arch/powerpc/mm/book3s64/hash_utils.c
index b8ad14bb1170..cebd1acaddac 100644
--- a/arch/powerpc/mm/book3s64/hash_utils.c
+++ b/arch/powerpc/mm/book3s64/hash_utils.c
@@ -1705,7 +1705,7 @@ void flush_hash_hugepage(unsigned long vsid, unsigned 
long addr,
/*
 * IF we try to do a HUGE PTE update after a withdraw is done.
 * we will find the below NULL. This happens when we do
-* split_huge_page_pmd
+* split_huge_pmd
 */
if (!hpte_slot_array)
return;
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 75d9d68a6de7..0e25f556a99b 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -1002,9 +1002,8 @@ static inline int 
pmd_none_or_trans_huge_or_clear_bad(pmd_t *pmd)
  * need this). If THP is not enabled, the pmd can't go away under the
  * code even if MADV_DONTNEED runs, but if THP is enabled we need to
  * run a pmd_trans_unstable before walking the ptes after
- * split_huge_page_pmd returns (because it may have run when the pmd
- * become null, but then a page fault can map in a THP and not a
- * regular page).
+ * split_huge_pmd returns (because it may have run when the pmd become
+ * null, but then a page fault can map in a THP and not a regular page).
  */
 static inline int pmd_trans_unstable(pmd_t *pmd)
 {
-- 
2.20.1

[PATCH] atm: iphase: Fix Spectre v1 vulnerability

[Gustavo A. R. Silva]

board is controlled by user-space, hence leading to a potential
exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/atm/iphase.c:2765 ia_ioctl() warn: potential spectre issue 'ia_dev' [r] 
(local cap)
drivers/atm/iphase.c:2774 ia_ioctl() warn: possible spectre second half.  
'iadev'
drivers/atm/iphase.c:2782 ia_ioctl() warn: possible spectre second half.  
'iadev'
drivers/atm/iphase.c:2816 ia_ioctl() warn: possible spectre second half.  
'iadev'
drivers/atm/iphase.c:2823 ia_ioctl() warn: possible spectre second half.  
'iadev'
drivers/atm/iphase.c:2830 ia_ioctl() warn: potential spectre issue '_ia_dev' 
[r] (local cap)
drivers/atm/iphase.c:2845 ia_ioctl() warn: possible spectre second half.  
'iadev'
drivers/atm/iphase.c:2856 ia_ioctl() warn: possible spectre second half.  
'iadev'

Fix this by sanitizing board before using it to index ia_dev and _ia_dev

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://lore.kernel.org/lkml/20180423164740.gy17...@dhcp22.suse.cz/

Cc: sta...@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/atm/iphase.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/atm/iphase.c b/drivers/atm/iphase.c
index 302cf0ba1600..8c7a996d1f16 100644
--- a/drivers/atm/iphase.c
+++ b/drivers/atm/iphase.c
@@ -63,6 +63,7 @@
 #include   
 #include 
 #include 
+#include 
 #include "iphase.h"  
 #include "suni.h"
 #define swap_byte_order(x) (((x & 0xff) << 8) | ((x & 0xff00) >> 8))
@@ -2760,8 +2761,11 @@ static int ia_ioctl(struct atm_dev *dev, unsigned int 
cmd, void __user *arg)
}
if (copy_from_user(_cmds, arg, sizeof ia_cmds)) return -EFAULT; 
board = ia_cmds.status;
-   if ((board < 0) || (board > iadev_count))
- board = 0;
+
+   if ((board < 0) || (board > iadev_count))
+   board = 0;
+   board = array_index_nospec(board, iadev_count + 1);
+
iadev = ia_dev[board];
switch (ia_cmds.cmd) {
case MEMDUMP:
-- 
2.22.0

[PATCH] watchdog: pc87413: Rewriting of pc87413_wdt driver to use watchdog subsystem

[Mark Balantzyan]

This patch rewrites the pc87413_wdt driver to use the watchdog subsystem. In
doing so, it also addresses a potential race condition owing from the
swc_base_addr variable being used before being set.

Signed-off-by: Mark Balantzyan 

---
 drivers/watchdog/Kconfig   |   1 +
 drivers/watchdog/pc87413_wdt.c | 323 -
 2 files changed, 40 insertions(+), 284 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 9af07fd9..84a7326d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1166,6 +1166,7 @@ config SCx200_WDT
 
 config PC87413_WDT
tristate "NS PC87413 watchdog"
+   select WATCHDOG_CORE
depends on X86
---help---
  This is the driver for the hardware watchdog on the PC87413 chipset
diff --git a/drivers/watchdog/pc87413_wdt.c b/drivers/watchdog/pc87413_wdt.c
index 06a892e3..60e3cda6 100644
--- a/drivers/watchdog/pc87413_wdt.c
+++ b/drivers/watchdog/pc87413_wdt.c
@@ -22,15 +22,9 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
@@ -60,13 +54,9 @@ static int swc_base_addr = -1;
 
 static int timeout = DEFAULT_TIMEOUT;  /* timeout value */
 static unsigned long timer_enabled;/* is the timer enabled? */
-
-static char expect_close;  /* is the close expected? */
-
-static DEFINE_SPINLOCK(io_lock);   /* to guard us from io races */
-
 static bool nowayout = WATCHDOG_NOWAYOUT;
 
+
 /* -- Low level function */
 
 /* Select pins for Watchdog output */
@@ -151,13 +141,15 @@ static inline void pc87413_swc_bank3(void)
 
 /* Set watchdog timeout to x minutes */
 
-static inline void pc87413_programm_wdto(char pc87413_time)
+static int pc87413_set_timeout(struct watchdog_device *wdd, unsigned int t)
 {
-   /* Step 5: Programm WDTO, Twd. */
-   outb_p(pc87413_time, swc_base_addr + WDTO);
-#ifdef DEBUG
-   pr_info(DPFX "Set WDTO to %d minutes\n", pc87413_time);
-#endif
+   /* Step 5: Programm watchdog timeout */
+
+   if ((t < 1) || ( t > 60))/* arbitrary upper limit */
+   return -EINVAL;
+   
+   timeout = t;
+   return 0;
 }
 
 /* Enable WDEN */
@@ -216,281 +208,61 @@ static inline void pc87413_disable_sw_wd_trg(void)
 
 /* -- Higher level functions */
 
-/* Enable the watchdog */
+/* Enable/start the watchdog */
 
-static void pc87413_enable(void)
+static int pc87413_start(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
+   return 0;
 }
 
-/* Disable the watchdog */
+/* Disable/stop the watchdog */
 
-static void pc87413_disable(void)
+static int pc87413_stop(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(0);
-
-   spin_unlock(_lock);
+   pc87413_set_timeout(wdd,0);
+   return 0;
 }
 
-/* Refresh the watchdog */
+/* Refresh/keepalive the watchdog */
 
-static void pc87413_refresh(void)
+static int pc87413_keepalive(struct watchdog_device *wdd)
 {
-   spin_lock(_lock);
-
pc87413_swc_bank3();
pc87413_disable_sw_wd_tren();
pc87413_disable_sw_wd_trg();
-   pc87413_programm_wdto(timeout);
+   pc87413_set_timeout(wdd,timeout);
pc87413_enable_wden();
pc87413_enable_sw_wd_tren();
pc87413_enable_sw_wd_trg();
-
-   spin_unlock(_lock);
-}
-
-/* -- File operations ---*/
-
-/**
- * pc87413_open:
- * @inode: inode of device
- * @file: file handle to device
- *
- */
-
-static int pc87413_open(struct inode *inode, struct file *file)
-{
-   /* /dev/watchdog can only be opened once */
-
-   if (test_and_set_bit(0, _enabled))
-   return -EBUSY;
-
-   if (nowayout)
-   __module_get(THIS_MODULE);
-
-   /* Reload and activate timer */
-   pc87413_refresh();
-
-   pr_info("Watchdog enabled. Timeout set to %d minute(s).\n", timeout);
-
-   return nonseekable_open(inode, file);
-}
-
-/**
- * pc87413_release:
- * @inode: inode to board
- * @file: file handle to board
- *
- * The watchdog has a configurable API. There is a religious dispute
- * between people who want their watchdog to be able to shut down and
- * those who want to be sure if the watchdog manager dies the machine
- * reboots. In the former case we disable the counters, in the latter
- * case you have to open it again very soon.
- */
-
-static int pc87413_release(struct inode *inode, struct file *file)
-{
-  

Re: [PATCH v3 8/9] x86/mm/tlb: Remove UV special case

[Nadav Amit]

> On Jul 18, 2019, at 7:25 PM, Mike Travis  wrote:
> 
> It is a fact that the UV is still the UV and SGI is now part of HPE. The
> current external product is known as SuperDome Flex. It is both up to date
> as well as very well maintained. The ACK I provided was an okay to change
> the code, but please make the description accurate.

Looking at the code again, if I remove the call to uv_flush_tlb_others(), is
there any use for tlb_uv.c?

Re: linux-next: build warnings after merge of the keys tree

[Stephen Rothwell]

Hi Eric,

On Tue, 30 Jul 2019 18:40:34 -0700 Eric Biggers  wrote:
>
> On Tue, Jul 30, 2019 at 01:52:16PM +1000, Stephen Rothwell wrote:
> > Hi Eric,
> > 
> > On Mon, 29 Jul 2019 20:47:04 -0700 Eric Biggers  
> > wrote:  
> > >
> > > On Tue, Jul 30, 2019 at 12:30:42PM +1000, Stephen Rothwell wrote:  
> > > > +static struct key_acl fsverity_acl = {
> > > > +   .usage  = REFCOUNT_INIT(1),
> > > > +   .possessor_viewable = true,
> > > 
> > > I don't think .possessor_viewable should be set here, since there's no
> > > KEY_POSSESSOR_ACE(KEY_ACE_VIEW) in the ACL.  David, this bool is supposed 
> > > to
> > > mean such an entry is present, right?  Is it really necessary, since it's
> > > redundant with the ACL itself?  
> > 
> > OK, I can take that out of the patch for tomorrow.
> >   
> > > Otherwise this looks good, thanks Stephen.  I'll want to remove a few of 
> > > these
> > > permissions in a separate patch later, but for now we can just keep it
> > > equivalent to the original code as you've done.  
> > 
> > Thanks for the review.
> 
> Hmm, apparently it's not *exactly* equivalent, since the ACL is missing INVAL
> and JOIN permission for the owner, while those were originally granted by 
> SEARCH
> permission.  We don't need those, but just to keep the merge resolution itself
> as boring as possible, can you please use the following to make it equivalent:
> 
> static struct key_acl fsverity_acl = {
>   .usage  = REFCOUNT_INIT(1),
>   .nr_ace = 2,
>   .aces = {
>   KEY_POSSESSOR_ACE(KEY_ACE_SEARCH | KEY_ACE_JOIN |
> KEY_ACE_INVAL),
>   KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ | KEY_ACE_WRITE |
> KEY_ACE_SEARCH | KEY_ACE_SET_SECURITY |
> KEY_ACE_INVAL | KEY_ACE_REVOKE | KEY_ACE_JOIN |
> KEY_ACE_CLEAR),
>   }
> };

OK, I have fixed up the patch for today (not quite as above, but
equivalently since I am editting a patch and I usually get that
wrong :-))

-- 
Cheers,
Stephen Rothwell


pgpyLPmeWzMdl.pgp
Description: OpenPGP digital signature

[PATCH v3 2/2] iio: tsl2772: Use regulator_bulk_() APIs

[Chuhong Yuan]

Use regulator_bulk_() APIs to shrink driver size.

Signed-off-by: Chuhong Yuan 
---
Changes in v3:
  - Split v2 into two patches.
  - Add dev_err to log error messages.
  - Add a check for EPROBE_DEFER.

 drivers/iio/light/tsl2772.c | 82 +++--
 1 file changed, 24 insertions(+), 58 deletions(-)

diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
index f1134f183be7..fd6d44297dba 100644
--- a/drivers/iio/light/tsl2772.c
+++ b/drivers/iio/light/tsl2772.c
@@ -134,6 +134,12 @@ enum {
TSL2772_CHIP_SUSPENDED = 2
 };
 
+enum {
+   TSL2772_SUPPLY_VDD = 0,
+   TSL2772_SUPPLY_VDDIO = 1,
+   TSL2772_NUM_SUPPLIES = 2
+};
+
 /* Per-device data */
 struct tsl2772_als_info {
u16 als_ch0;
@@ -161,8 +167,7 @@ struct tsl2772_chip {
struct mutex prox_mutex;
struct mutex als_mutex;
struct i2c_client *client;
-   struct regulator *vdd_supply;
-   struct regulator *vddio_supply;
+   struct regulator_bulk_data reg[TSL2772_NUM_SUPPLIES];
u16 prox_data;
struct tsl2772_als_info als_cur_info;
struct tsl2772_settings settings;
@@ -697,46 +702,7 @@ static void tsl2772_disable_regulators_action(void *_data)
 {
struct tsl2772_chip *chip = _data;
 
-   regulator_disable(chip->vdd_supply);
-   regulator_disable(chip->vddio_supply);
-}
-
-static int tsl2772_enable_regulator(struct tsl2772_chip *chip,
-   struct regulator *regulator)
-{
-   int ret;
-
-   ret = regulator_enable(regulator);
-   if (ret < 0) {
-   dev_err(>client->dev, "Failed to enable regulator: %d\n",
-   ret);
-   return ret;
-   }
-
-   return 0;
-}
-
-static struct regulator *tsl2772_get_regulator(struct tsl2772_chip *chip,
-  char *name)
-{
-   struct regulator *regulator;
-   int ret;
-
-   regulator = devm_regulator_get(>client->dev, name);
-   if (IS_ERR(regulator)) {
-   if (PTR_ERR(regulator) != -EPROBE_DEFER)
-   dev_err(>client->dev,
-   "Failed to get %s regulator %d\n",
-   name, (int)PTR_ERR(regulator));
-
-   return regulator;
-   }
-
-   ret = tsl2772_enable_regulator(chip, regulator);
-   if (ret < 0)
-   return ERR_PTR(ret);
-
-   return regulator;
+   regulator_bulk_disable(ARRAY_SIZE(chip->reg), chip->reg);
 }
 
 static int tsl2772_chip_on(struct iio_dev *indio_dev)
@@ -1804,14 +1770,21 @@ static int tsl2772_probe(struct i2c_client *clientp,
chip->client = clientp;
i2c_set_clientdata(clientp, indio_dev);
 
-   chip->vddio_supply = tsl2772_get_regulator(chip, "vddio");
-   if (IS_ERR(chip->vddio_supply))
-   return PTR_ERR(chip->vddio_supply);
+   chip->reg[TSL2772_SUPPLY_VDD].supply = "vdd";
+   chip->reg[TSL2772_SUPPLY_VDDIO].supply = "vddio";
 
-   chip->vdd_supply = tsl2772_get_regulator(chip, "vdd");
-   if (IS_ERR(chip->vdd_supply)) {
-   regulator_disable(chip->vddio_supply);
-   return PTR_ERR(chip->vdd_supply);
+   ret = devm_regulator_bulk_get(>dev, ARRAY_SIZE(chip->reg),
+   chip->reg);
+   if (ret < 0) {
+   if (ret != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get regulators: 
%d\n", ret);
+   return ret;
+   }
+
+   ret = regulator_bulk_enable(ARRAY_SIZE(chip->reg), chip->reg);
+   if (ret < 0) {
+   dev_err(>dev, "Failed to enable regulators: %d\n", 
ret);
+   return ret;
}
 
ret = devm_add_action_or_reset(>dev,
@@ -1901,8 +1874,7 @@ static int tsl2772_suspend(struct device *dev)
int ret;
 
ret = tsl2772_chip_off(indio_dev);
-   regulator_disable(chip->vdd_supply);
-   regulator_disable(chip->vddio_supply);
+   regulator_bulk_disable(ARRAY_SIZE(chip->reg), chip->reg);
 
return ret;
 }
@@ -1913,16 +1885,10 @@ static int tsl2772_resume(struct device *dev)
struct tsl2772_chip *chip = iio_priv(indio_dev);
int ret;
 
-   ret = tsl2772_enable_regulator(chip, chip->vddio_supply);
+   ret = regulator_bulk_enable(ARRAY_SIZE(chip->reg), chip->reg);
if (ret < 0)
return ret;
 
-   ret = tsl2772_enable_regulator(chip, chip->vdd_supply);
-   if (ret < 0) {
-   regulator_disable(chip->vddio_supply);
-   return ret;
-   }
-
usleep_range(TSL2772_BOOT_MIN_SLEEP_TIME, TSL2772_BOOT_MAX_SLEEP_TIME);
 
return tsl2772_chip_on(indio_dev);
-- 
2.20.1

[PATCH v3 1/2] iio: tsl2772: Use device-managed API

[Chuhong Yuan]

Use devm_() APIs to simplify the code.

Signed-off-by: Chuhong Yuan 
---
Changes in v3:
  - Split v2 into two patches.

 drivers/iio/light/tsl2772.c | 36 +++-
 1 file changed, 15 insertions(+), 21 deletions(-)

diff --git a/drivers/iio/light/tsl2772.c b/drivers/iio/light/tsl2772.c
index 83cece921843..f1134f183be7 100644
--- a/drivers/iio/light/tsl2772.c
+++ b/drivers/iio/light/tsl2772.c
@@ -860,6 +860,13 @@ static int tsl2772_chip_off(struct iio_dev *indio_dev)
return tsl2772_write_control_reg(chip, 0x00);
 }
 
+static void tsl2772_chip_off_action(void *data)
+{
+   struct iio_dev *indio_dev = data;
+
+   tsl2772_chip_off(indio_dev);
+}
+
 /**
  * tsl2772_invoke_change - power cycle the device to implement the user
  * parameters
@@ -1807,10 +1814,10 @@ static int tsl2772_probe(struct i2c_client *clientp,
return PTR_ERR(chip->vdd_supply);
}
 
-   ret = devm_add_action(>dev, tsl2772_disable_regulators_action,
+   ret = devm_add_action_or_reset(>dev,
+   tsl2772_disable_regulators_action,
  chip);
if (ret < 0) {
-   tsl2772_disable_regulators_action(chip);
dev_err(>dev, "Failed to setup regulator cleanup 
action %d\n",
ret);
return ret;
@@ -1877,15 +1884,14 @@ static int tsl2772_probe(struct i2c_client *clientp,
if (ret < 0)
return ret;
 
-   ret = iio_device_register(indio_dev);
-   if (ret) {
-   tsl2772_chip_off(indio_dev);
-   dev_err(>dev,
-   "%s: iio registration failed\n", __func__);
+   ret = devm_add_action_or_reset(>dev,
+   tsl2772_chip_off_action,
+   indio_dev);
+
+   if (ret < 0)
return ret;
-   }
 
-   return 0;
+   return devm_iio_device_register(>dev, indio_dev);
 }
 
 static int tsl2772_suspend(struct device *dev)
@@ -1922,17 +1928,6 @@ static int tsl2772_resume(struct device *dev)
return tsl2772_chip_on(indio_dev);
 }
 
-static int tsl2772_remove(struct i2c_client *client)
-{
-   struct iio_dev *indio_dev = i2c_get_clientdata(client);
-
-   tsl2772_chip_off(indio_dev);
-
-   iio_device_unregister(indio_dev);
-
-   return 0;
-}
-
 static const struct i2c_device_id tsl2772_idtable[] = {
{ "tsl2571", tsl2571 },
{ "tsl2671", tsl2671 },
@@ -1979,7 +1974,6 @@ static struct i2c_driver tsl2772_driver = {
},
.id_table = tsl2772_idtable,
.probe = tsl2772_probe,
-   .remove = tsl2772_remove,
 };
 
 module_i2c_driver(tsl2772_driver);
-- 
2.20.1

Re: [PATCH v5.3-rc2] Bluetooth: hci_uart: check for missing tty operations

[Al Cho]

On Tue, 2019-07-30 at 11:33 +0200, Marcel Holtmann wrote:
> From: Vladis Dronov 
> 
> Certain ttys operations (pty_unix98_ops) lack tiocmget() and
> tiocmset()
> functions which are called by the certain HCI UART protocols
> (hci_ath,
> hci_bcm, hci_intel, hci_mrvl, hci_qca) via
> hci_uart_set_flow_control()
> or directly. This leads to an execution at NULL and can be triggered
> by
> an unprivileged user. Fix this by adding a helper function and a
> check
> for the missing tty operations in the protocols code.
> 
> This fixes CVE-2019-10207. The Fixes: lines list commits where calls
> to
> tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI
> UART
> protocols.
> 
> Link: 
> https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50
> Reported-by: syzbot+79337b501d6aa974d...@syzkaller.appspotmail.com
> Cc: sta...@vger.kernel.org # v2.6.36+
> Fixes: b3190df62861 ("Bluetooth: Support for Atheros AR300x serial
> chip")
> Fixes: 118612fb9165 ("Bluetooth: hci_bcm: Add suspend/resume PM
> functions")
> Fixes: ff2895592f0f ("Bluetooth: hci_intel: Add Intel baudrate
> configuration support")
> Fixes: 162f812f23ba ("Bluetooth: hci_uart: Add Marvell support")
> Fixes: fa9ad876b8e0 ("Bluetooth: hci_qca: Add support for Qualcomm
> Bluetooth chip wcn3990")
> Signed-off-by: Vladis Dronov 
> Signed-off-by: Marcel Holtmann 

Reviewed-by: Yu-Chen, Cho 
Tested-by: Yu-Chen, Cho 

> ---
>  drivers/bluetooth/hci_ath.c   |  3 +++
>  drivers/bluetooth/hci_bcm.c   |  3 +++
>  drivers/bluetooth/hci_intel.c |  3 +++
>  drivers/bluetooth/hci_ldisc.c | 13 +
>  drivers/bluetooth/hci_mrvl.c  |  3 +++
>  drivers/bluetooth/hci_qca.c   |  3 +++
>  drivers/bluetooth/hci_uart.h  |  1 +
>  7 files changed, 29 insertions(+)
> 
> diff --git a/drivers/bluetooth/hci_ath.c
> b/drivers/bluetooth/hci_ath.c
> index a55be205b91a..dbfe34664633 100644
> --- a/drivers/bluetooth/hci_ath.c
> +++ b/drivers/bluetooth/hci_ath.c
> @@ -98,6 +98,9 @@ static int ath_open(struct hci_uart *hu)
>  
>   BT_DBG("hu %p", hu);
>  
> + if (!hci_uart_has_flow_control(hu))
> + return -EOPNOTSUPP;
> +
>   ath = kzalloc(sizeof(*ath), GFP_KERNEL);
>   if (!ath)
>   return -ENOMEM;
> diff --git a/drivers/bluetooth/hci_bcm.c
> b/drivers/bluetooth/hci_bcm.c
> index 8905ad2edde7..ae2624fce913 100644
> --- a/drivers/bluetooth/hci_bcm.c
> +++ b/drivers/bluetooth/hci_bcm.c
> @@ -406,6 +406,9 @@ static int bcm_open(struct hci_uart *hu)
>  
>   bt_dev_dbg(hu->hdev, "hu %p", hu);
>  
> + if (!hci_uart_has_flow_control(hu))
> + return -EOPNOTSUPP;
> +
>   bcm = kzalloc(sizeof(*bcm), GFP_KERNEL);
>   if (!bcm)
>   return -ENOMEM;
> diff --git a/drivers/bluetooth/hci_intel.c
> b/drivers/bluetooth/hci_intel.c
> index 207bae5e0d46..31f25153087d 100644
> --- a/drivers/bluetooth/hci_intel.c
> +++ b/drivers/bluetooth/hci_intel.c
> @@ -391,6 +391,9 @@ static int intel_open(struct hci_uart *hu)
>  
>   BT_DBG("hu %p", hu);
>  
> + if (!hci_uart_has_flow_control(hu))
> + return -EOPNOTSUPP;
> +
>   intel = kzalloc(sizeof(*intel), GFP_KERNEL);
>   if (!intel)
>   return -ENOMEM;
> diff --git a/drivers/bluetooth/hci_ldisc.c
> b/drivers/bluetooth/hci_ldisc.c
> index 8950e07889fe..85a30fb9177b 100644
> --- a/drivers/bluetooth/hci_ldisc.c
> +++ b/drivers/bluetooth/hci_ldisc.c
> @@ -292,6 +292,19 @@ static int hci_uart_send_frame(struct hci_dev
> *hdev, struct sk_buff *skb)
>   return 0;
>  }
>  
> +/* Check the underlying device or tty has flow control support */
> +bool hci_uart_has_flow_control(struct hci_uart *hu)
> +{
> + /* serdev nodes check if the needed operations are present */
> + if (hu->serdev)
> + return true;
> +
> + if (hu->tty->driver->ops->tiocmget && hu->tty->driver->ops-
> >tiocmset)
> + return true;
> +
> + return false;
> +}
> +
>  /* Flow control or un-flow control the device */
>  void hci_uart_set_flow_control(struct hci_uart *hu, bool enable)
>  {
> diff --git a/drivers/bluetooth/hci_mrvl.c
> b/drivers/bluetooth/hci_mrvl.c
> index f98e5cc343b2..fbc3f7c3a5c7 100644
> --- a/drivers/bluetooth/hci_mrvl.c
> +++ b/drivers/bluetooth/hci_mrvl.c
> @@ -59,6 +59,9 @@ static int mrvl_open(struct hci_uart *hu)
>  
>   BT_DBG("hu %p", hu);
>  
> + if (!hci_uart_has_flow_control(hu))
> + return -EOPNOTSUPP;
> +
>   mrvl = kzalloc(sizeof(*mrvl), GFP_KERNEL);
>   if (!mrvl)
>   return -ENOMEM;
> diff --git a/drivers/bluetooth/hci_qca.c
> b/drivers/bluetooth/hci_qca.c
> index 9a5c9c1f9484..82a0a3691a63 100644
> --- a/drivers/bluetooth/hci_qca.c
> +++ b/drivers/bluetooth/hci_qca.c
> @@ -473,6 +473,9 @@ static int qca_open(struct hci_uart *hu)
>  
>   BT_DBG("hu %p qca_open", hu);
>  
> + if (!hci_uart_has_flow_control(hu))
> + return -EOPNOTSUPP;
> +
>   qca = kzalloc(sizeof(struct qca_data), GFP_KERNEL);
>   if (!qca)
> 

Re: [PATCH 0/7] media: vimc: Add a V4L2 output device

[André Almeida]

On 7/13/19 7:03 AM, Hans Verkuil wrote:
> On 7/12/19 5:38 PM, André Almeida wrote:
>> Hello,
>>
>> On 7/10/19 4:33 AM, Hans Verkuil wrote:
>>> On 7/10/19 12:19 AM, Helen Koike wrote:
 Hi André,

 Thanks for the patches.

 On 7/2/19 12:47 PM, André Almeida wrote:
> Hello,
>
> This patch adds a V4L2 output device on vimc, that comply with V4L2 API
> for video output. If there is an output device and a capture device at the
> same pipeline, one can get a video loopback pipeline feeding frames at
> the output and then seeing them at the capture. It's possible to insert
> vimc submodules at the pipeline to modify the image (e.g. a scaler).
>
> If one starts a streaming at the capture, with the output off, the
> capture will display a noisy frame. If one starts a streaming at the
> output with the capture off, the output will just consume the buffers,
> without sending them to the pipeline. If both output and capture are
> streaming, the loopback will happen.
 I understand why it is done like this in vivid, but I was wondering, if we
 have a pipeline like:
 output -> capture
 Shouldn't streaming from the capture just stalls if there is no frame
 available in the output (i.e. streaming in the output is off) ? But then 
 I'm
 not sure what the framerate in the capture would mean.

 Hans, what do you think?
>>> If you set up the pipeline like this:
>>>
>>> Video Output -> Scaler -> Video Capture
>>
>> If the capture will stall if there's no frame from the video output, how
>> can I add support for this kind of pipeline at test-media? It would be
>> required to send frames to the output device while running
>> `v4l2-compliance` at the capture device to make testing possible.
> 
> The compliance test doesn't support such devices at the moment.

The implementation of the expected behavior can be found here:
https://gitlab.collabora.com/tonyk/linux/tree/vimc/output-v2

> 
> I think a new option (or options) are needed to tell the compliance test
> that the capture and output video devices together constitute an m2m device.

I've reading the v4l-utils code base and I had a look at both m2m tests
and capture/output tests, but I'm not sure how to implement this new
option. How do you think it should be implemented? Should it resemble
how v4l2-compliance tests vim2m? Something like this:

v4l2-compliance -m platform:vim2m -z platform:vivid-002 -e
vivid-002-vid-cap -s10 -P -a

Thanks,
André

> 
> Regards,
> 
>   Hans
> 
>>
>> Thanks,
>>     André
>>
>>> Then this is a mem2mem device (except with two separate video devices) and
>>> framerate doesn't apply anymore. And video capture will just stall if there
>>> is no video output frame provided.
>>>
>>> It's how e.g. omap3isp works.
>>>
>>> Regards,
>>>
>>> Hans
>>>
 Thanks,
 Helen

> The patches 1 and 2 provide some ground to create the output
> device. The patch 3 creates the device and modify how the vimc-streamer
> was dealing with the s_stream callback on other vimc modules, to make
> simpler implementing this callback at vimc-output. Patch 4 change the
> behavior of the pipeline in order to be closer to a real life hardware.
> Patches 5-7 updates the default pipeline and the documentation to
> include the new output device.
>
> This is the result of v4l2-compliance after this patch series:
> $ v4l2-compliance -m0 -s50
> Grand Total for vimc device /dev/media0: 476, Succeeded: 476, Failed: 0,
> Warnings: 0
>
> A git tree up to date with media-master and with this changes can be found
> at: https://gitlab.collabora.com/tonyk/linux/tree/vimc/output
>
> In order to test it, one can follow these instructions:
>
> 1 - Configure the pipeline (requires v4l-utils):
>
> $ media-ctl -d platform:vimc -V '"Sensor A":0[fmt:SBGGR8_1X8/640x480]'
> $ media-ctl -d platform:vimc -V '"Debayer A":0[fmt:SBGGR8_1X8/640x480]'
> $ media-ctl -d platform:vimc -V '"Sensor B":0[fmt:SBGGR8_1X8/640x480]'
> $ media-ctl -d platform:vimc -V '"Debayer B":0[fmt:SBGGR8_1X8/640x480]'
> $ v4l2-ctl -z platform:vimc -d "RGB/YUV Capture" -v width=1920,height=1440
> $ v4l2-ctl -z platform:vimc -d "Raw Capture 0" -v pixelformat=BA81
> $ v4l2-ctl -z platform:vimc -d "Raw Capture 1" -v pixelformat=BA81
> $ v4l2-ctl -z platform:vimc -e "RGB/YUV Input" -v width=640,height=480
>
> 2 - Use a userspace application:
> 2.a gst-launch (requires gstreamer and gst-plugins-good):
>
> Feed frames into the output and grab from the capture (rescaled for
> convenience):
>
> $ gst-launch-1.0 videotestsrc pattern=ball ! \
>   video/x-raw,width=640,height=480,format=RGB \
>   ! v4l2sink device=/dev/video2 v4l2src device=/dev/video3 ! \
>   video/x-raw,width=1920,height=1440,format=RGB ! videoscale ! \
>   

[PATCH] cpufreq: schedutil: Don't skip freq update when limits change

[Viresh Kumar]

To avoid reducing the frequency of a CPU prematurely, we skip reducing
the frequency if the CPU had been busy recently.

This should not be done when the limits of the policy are changed, for
example due to thermal throttling. We should always get the frequency
within the new limits as soon as possible.

Fixes: ecd288429126 ("cpufreq: schedutil: Don't set next_freq to UINT_MAX")
Cc: v4.18+  # v4.18+
Reported-by: Doug Smythies 
Signed-off-by: Viresh Kumar 
---
@Doug: Can you please provide your Tested-by for this commit, as it
already fixed the issue around acpi-cpufreq driver.

We will continue to see what's wrong with intel-pstate though.

 kernel/sched/cpufreq_schedutil.c | 17 -
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 636ca6f88c8e..2f382b0959e5 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -40,6 +40,7 @@ struct sugov_policy {
struct task_struct  *thread;
boolwork_in_progress;
 
+   boollimits_changed;
boolneed_freq_update;
 };
 
@@ -89,8 +90,11 @@ static bool sugov_should_update_freq(struct sugov_policy 
*sg_policy, u64 time)
!cpufreq_this_cpu_can_update(sg_policy->policy))
return false;
 
-   if (unlikely(sg_policy->need_freq_update))
+   if (unlikely(sg_policy->limits_changed)) {
+   sg_policy->limits_changed = false;
+   sg_policy->need_freq_update = true;
return true;
+   }
 
delta_ns = time - sg_policy->last_freq_update_time;
 
@@ -437,7 +441,7 @@ static inline bool sugov_cpu_is_busy(struct sugov_cpu 
*sg_cpu) { return false; }
 static inline void ignore_dl_rate_limit(struct sugov_cpu *sg_cpu, struct 
sugov_policy *sg_policy)
 {
if (cpu_bw_dl(cpu_rq(sg_cpu->cpu)) > sg_cpu->bw_dl)
-   sg_policy->need_freq_update = true;
+   sg_policy->limits_changed = true;
 }
 
 static void sugov_update_single(struct update_util_data *hook, u64 time,
@@ -447,7 +451,7 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
unsigned long util, max;
unsigned int next_f;
-   bool busy;
+   bool busy = false;
 
sugov_iowait_boost(sg_cpu, time, flags);
sg_cpu->last_update = time;
@@ -457,7 +461,9 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
if (!sugov_should_update_freq(sg_policy, time))
return;
 
-   busy = sugov_cpu_is_busy(sg_cpu);
+   /* Limits may have changed, don't skip frequency update */
+   if (!sg_policy->need_freq_update)
+   busy = sugov_cpu_is_busy(sg_cpu);
 
util = sugov_get_util(sg_cpu);
max = sg_cpu->max;
@@ -831,6 +837,7 @@ static int sugov_start(struct cpufreq_policy *policy)
sg_policy->last_freq_update_time= 0;
sg_policy->next_freq= 0;
sg_policy->work_in_progress = false;
+   sg_policy->limits_changed   = false;
sg_policy->need_freq_update = false;
sg_policy->cached_raw_freq  = 0;
 
@@ -879,7 +886,7 @@ static void sugov_limits(struct cpufreq_policy *policy)
mutex_unlock(_policy->work_lock);
}
 
-   sg_policy->need_freq_update = true;
+   sg_policy->limits_changed = true;
 }
 
 struct cpufreq_governor schedutil_gov = {
-- 
2.21.0.rc0.269.g1a574e7a288b

Re: Reminder: 99 open syzbot bugs in net subsystem

[Eric Biggers]

On Thu, Jul 25, 2019 at 07:04:47AM +0200, Eric Dumazet wrote:
> 
> 
> On 7/24/19 11:09 PM, Eric Biggers wrote:
> > On Wed, Jul 24, 2019 at 01:09:28PM -0700, David Miller wrote:
> >> From: Eric Biggers 
> >> Date: Wed, 24 Jul 2019 11:37:12 -0700
> >>
> >>> We can argue about what words to use to describe this situation, but
> >>> it doesn't change the situation itself.
> >>
> >> And we should argue about those words because it matters to humans and
> >> effects how they feel, and humans ultimately fix these bugs.
> >>
> >> So please stop with the hyperbole.
> >>
> >> Thank you.
> > 
> > Okay, there are 151 bugs that syzbot saw on the mainline Linux kernel in the
> > last 7 days (90.1% with reproducers).  Of those, 59 were reported over 3 
> > months
> > ago (89.8% with reproducers).  Of those, 12 were reported over a year ago 
> > (83.3%
> > with reproducers).
> > 
> > No opinion on whether those are small/medium/large numbers, in case it would
> > hurt someone's feelings.
> > 
> > These numbers do *not* include bugs that are still valid but weren't seen on
> > mainline in last 7 days, e.g.:
> > 
> > - Bugs that are seen only rarely, so by chance weren't seen in last 7 days.
> > - Bugs only in linux-next and/or subsystem branches.
> > - Bugs that were seen in mainline more than 7 days ago, and then only on
> >   linux-next or subsystem branch in last 7 days.
> > - Bugs that stopped being seen due to a change in syzkaller.
> > - Bugs that stopped being seen due to a change in kernel config.
> > - Bugs that stopped being seen due to other environment changes such as 
> > kernel
> >   command line parameters.
> > - Bugs that stopped being seen due to a kernel change that hid the bug but
> >   didn't actually fix it, i.e. still reachable in other ways.
> > 
> 
> We do not doubt syzkaller is an incredible tool.
> 
> But netdev@ and lkml@ are mailing lists for humans to interact,
> exchange ideas, send patches and review them.
> 
> To me, an issue that was reported to netdev by a real user is _way_ more 
> important
> than potential issues that a bot might have found doing crazy things.
> 
> We need to keep optimal S/N on mailing lists, so any bots trying to interact
> with these lists must be very cautious and damn smart.
> 
> When I have time to spare and can work on syzbot reports, I am going to a web
> page where I can see them and select the ones it makes sense to fix.
> I hate having to set up email filters.
> 

syzbot finds a lot of security bugs, and security bugs are important.  And the
bugs are still there regardless of whether they're reported by human or bot.

Also, there *are* bugs being fixed because of these reminders; some subsystem
maintainers have even fixed all the bugs in their subsystem.  But I can
understand that for subsystems with a lot of open bug reports it's overwhelming.

What I'll try doing next time (if there *is* a next time; it isn't actually my
job to do any of this, I just care about the security and reliability of
Linux...) is for subsystems with lots of open bug reports, only listing the ones
actually seen in the last week or so, and perhaps also spending some more time
manually checking those bugs.  That should cut down the noise a lot.

- Eric

Re: [PATCH v4 03/10] livepatch: Add klp-convert tool

[Masahiro Yamada]

On Thu, May 9, 2019 at 11:39 PM Joe Lawrence  wrote:
>
> From: Josh Poimboeuf 
>
> Livepatches may use symbols which are not contained in its own scope,
> and, because of that, may end up compiled with relocations that will
> only be resolved during module load. Yet, when the referenced symbols
> are not exported, solving this relocation requires information on the
> object that holds the symbol (either vmlinux or modules) and its
> position inside the object, as an object may contain multiple symbols
> with the same name. Providing such information must be done
> accordingly to what is specified in
> Documentation/livepatch/module-elf-format.txt.
>
> Currently, there is no trivial way to embed the required information
> as requested in the final livepatch elf object. klp-convert solves
> this problem in two different forms: (i) by relying on Symbols.list,
> which is built during kernel compilation, to automatically infer the
> relocation targeted symbol, and, when such inference is not possible
> (ii) by using annotations in the elf object to convert the relocation
> accordingly to the specification, enabling it to be handled by the
> livepatch loader.
>
> Given the above, create scripts/livepatch to hold tools developed for
> livepatches and add source files for klp-convert there.
>
> The core file of klp-convert is scripts/livepatch/klp-convert.c, which
> implements the heuristics used to solve the relocations and the
> conversion of unresolved symbols into the expected format, as defined
> in [1].
>
> klp-convert receives as arguments the Symbols.list file, an input
> livepatch module to be converted and the output name for the converted
> livepatch. When it starts running, klp-convert parses Symbols.list and
> builds two internal lists of symbols, one containing the exported and
> another containing the non-exported symbols. Then, by parsing the rela
> sections in the elf object, klp-convert identifies which symbols must
> be converted, which are those unresolved and that do not have a
> corresponding exported symbol, and attempts to convert them
> accordingly to the specification.
>
> By using Symbols.list, klp-convert identifies which symbols have names
> that only appear in a single kernel object, thus being capable of
> resolving these cases without the intervention of the developer. When
> various homonymous symbols exist through kernel objects, it is not
> possible to infer the right one, thus klp-convert falls back into
> using developer annotations. If these were not provided, then the tool
> will print a list with all acceptable targets for the symbol being
> processed.
>
> Annotations in the context of klp-convert are accessible as struct
> klp_module_reloc entries in sections named
> .klp.module_relocs.. These entries are pairs of symbol
> references and positions which are to be resolved against definitions
> in .
>
> Define the structure klp_module_reloc in
> include/linux/uapi/livepatch.h allowing developers to annotate the
> livepatch source code with it.
>
> klp-convert relies on libelf and on a list implementation. Add files
> scripts/livepatch/elf.c and scripts/livepatch/elf.h, which are a
> libelf interfacing layer and scripts/livepatch/list.h, which is a
> list implementation.
>
> Update Makefiles to correctly support the compilation of the new tool,
> update MAINTAINERS file and add a .gitignore file.
>
> [1] - Documentation/livepatch/module-elf-format.txt
>
> Signed-off-by: Josh Poimboeuf 
> Signed-off-by: Konstantin Khlebnikov 
> Signed-off-by: Joao Moreira 
> Signed-off-by: Joe Lawrence 
> ---
>  MAINTAINERS |   1 +
>  include/uapi/linux/livepatch.h  |   5 +
>  scripts/Makefile|   1 +
>  scripts/livepatch/.gitignore|   1 +
>  scripts/livepatch/Makefile  |   7 +
>  scripts/livepatch/elf.c | 753 
>  scripts/livepatch/elf.h |  73 
>  scripts/livepatch/klp-convert.c | 713 ++
>  scripts/livepatch/klp-convert.h |  39 ++
>  scripts/livepatch/list.h| 391 +
>  10 files changed, 1984 insertions(+)
>  create mode 100644 scripts/livepatch/.gitignore
>  create mode 100644 scripts/livepatch/Makefile
>  create mode 100644 scripts/livepatch/elf.c
>  create mode 100644 scripts/livepatch/elf.h
>  create mode 100644 scripts/livepatch/klp-convert.c
>  create mode 100644 scripts/livepatch/klp-convert.h
>  create mode 100644 scripts/livepatch/list.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 52842fa37261..c1587e1cc385 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9022,6 +9022,7 @@ F:arch/x86/kernel/livepatch.c
>  F: Documentation/livepatch/
>  F: Documentation/ABI/testing/sysfs-kernel-livepatch
>  F: samples/livepatch/
> +F: scripts/livepatch/
>  F: tools/testing/selftests/livepatch/
>  L: live-patch...@vger.kernel.org
>  T: git 
> 

Re: [RFC PATCH v3 00/16] Core scheduling v3

[Li, Aubrey]

On 2019/7/26 23:21, Julien Desfossez wrote:
> On 25-Jul-2019 10:30:03 PM, Aaron Lu wrote:
>>
>> I tried a different approach based on vruntime with 3 patches following.
> [...]
> 
> We have experimented with this new patchset and indeed the fairness is
> now much better. Interactive tasks with v3 were complete starving when
> there were cpu-intensive tasks running, now they can run consistently.

Yeah, the fairness is much better now.

For two cgroups created, I limited the cpuset to be one core(two siblings)
of these two cgroups, I still run gemmbench and sysbench-mysql, and here
is the mysql result:

Latency:
.--.
|NA/AVX vanilla-SMT [std% / sem%] cpu% |coresched-SMT   [std% / sem%]   
  +/- cpu% |
|--|
|  1/1  6.7 [13.8%/ 1.4%] 2.1% |  6.4   [14.6%/ 1.5%]   
  4.0%2.0% |
|  2/2  9.1 [ 5.0%/ 0.5%] 4.0% | 11.4   [ 6.8%/ 0.7%]   
-24.9%3.9% |
'--'

Throughput:
.--.
|NA/AVX vanilla-SMT [std% / sem%] cpu% |coresched-SMT   [std% / sem%]   
  +/- cpu% |
|--|
|  1/1310.2 [ 4.1%/ 0.4%] 2.1% |296.2   [ 5.0%/ 0.5%]   
 -4.5%2.0% | 
|  2/2547.7 [ 3.6%/ 0.4%] 4.0% |368.3   [ 4.8%/ 0.5%]   
-32.8%3.9% | 
'--'

Note: 2/2 case means 4 threads run on one core, which is overloaded.(cpu% is 
overall system report)

Though the latency/throughput has regressions, but standard deviation is much 
better now.

> With my initial test of TPC-C running in large VMs with a lot of
> background noise VMs, the results are pretty similar to v3, I will run
> more thorough tests and report the results back here.

I see something similar. I guess task placement could be another problem.
We don't check cookie matching in load balance and task wakeup, so
- if tasks with different cookie happen to be dispatched onto different cores,
The result should be good
- if tasks with different cookie are unfortunately dispatched onto the same
core, the result should be bad.

This problem is bypassed in my testing setup above, but may be one cause
of my other scenarios, need a while to sort out.

Thanks,
-Aubrey

Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S

[Andrew Lunn]

> Hi Andrew,
> 
> The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over 
> backplane (1000Base-KX).

Ah, that is different. So the board is using it for RGMII to 1000Base-KX?

phy-mode is about the MAC-PHY link. So in this case RGMII.

There is no DT way to configure the PHY-Switch link. However, it
sounds like you have the PHY strapped so it is doing 1000BaseX on the
PHY-Switch link. So do you actually need to configure this?

You report you never see link up? So maybe the problem is actually in
read_status? When in 1000BaseX mode, do you need to read the link
status from some other register? The Marvell PHYs use a second page
for 1000BaseX.

Andrew

Re: Reminder: 1 open syzbot bug in rtc subsystem

[Eric Biggers]

On Mon, Jul 29, 2019 at 03:47:45PM +0800, Hillf Danton wrote:
> 
> On Tue, 23 Jul 2019 19:50:08 -0700
> > 
> > [This email was generated by a script.  Let me know if you have any 
> > suggestions
> > to make it better, or if you want it re-generated with the latest status.]
> > 
> > Of the currently open syzbot reports against the upstream kernel, I've 
> > manually
> > marked 1 of them as possibly being a bug in the rtc subsystem.
> > 
> > If you believe this bug is no longer valid, please close the syzbot report 
> > by
> > sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> > original thread, as explained at https://goo.gl/tpsmEJ#status
> > 
> > If you believe I misattributed this bug to the rtc subsystem, please let me
> > know, and if possible forward the report to the correct people or mailing 
> > list.
> > 
> > Here is the bug:
> > 
> > 
> > Title:  BUG: workqueue lockup (4)
> > Last occurred:  40 days ago
> > Reported:   289 days ago
> > Branches:   Mainline and others
> > Dashboard link: 
> > https://syzkaller.appspot.com/bug?id=0041bf1423916e9ae458b08b760e269a33c14960
> > Original thread:
> > https://lkml.kernel.org/lkml/5764090577a27...@google.com/T/#u
> > 
> Better if %s=lkml.kernel.org=lore.kernel.org=
> 

Out of curiosity, is there a reason for this?  They both go to the same place,
but the reason I used lkml.kernel.org is that some high-profile kernel
developers (e.g. Andrew Morton) are using it in the "Link: " tag in commits.
So it seems like lkml.kernel.org is maybe "right" one that is intended to
always keep working in the future?

But then I see Greg KH is using lore.kernel.org, so maybe it doesn't matter?

Maybe lore.kernel.org is better because people won't confuse it with lkml.org
and refuse to go to it :-)

- Eric

Re: Reminder: 1 open syzbot bug in rtc subsystem

[Eric Biggers]

On Sun, Jul 28, 2019 at 03:23:33PM +0200, Pavel Machek wrote:
> On Tue 2019-07-23 19:50:08, Eric Biggers wrote:
> > [This email was generated by a script.  Let me know if you have any 
> > suggestions
> > to make it better, or if you want it re-generated with the latest status.]
> > 
> > Of the currently open syzbot reports against the upstream kernel, I've 
> > manually
> > marked 1 of them as possibly being a bug in the rtc subsystem.
> > 
> > If you believe this bug is no longer valid, please close the syzbot report 
> > by
> > sending a '#syz fix', '#syz dup', or '#syz invalid' command in reply to the
> > original thread, as explained at https://goo.gl/tpsmEJ#status
> > 
> > If you believe I misattributed this bug to the rtc subsystem, please let me
> > know, and if possible forward the report to the correct people or mailing 
> > list.
> > 
> > Here is the bug:
> 
> 
> Can you stop spamming lkml?
> 
> Sending 20 "reminders" in a row is not something human would do, and it is not
> something your bot should be allowed to do, either.
> 

Hi Pavel, just to clarify, though I used a script to generate these emails, I
manually reviewed and sent each one; I also manually assigned the subsystems and
sanity checked the bisection results.  (I'm also not on the syzbot team.  I just
care about the security and reliability of the Linux kernel...)  The reason
there are so many of these emails is that there are a lot of kernel subsystems
with open bug reports, many clearly still valid -- even considering that I
decided to skip some subsystems after deciding to just fix the bugs myself,
update the bug statuses myself, send some other email, or just wait.

I suppose there's some argument to be made that it's too noisy to Cc
linux-kernel when I've already assigned a subsystem, though, so I'll try
dropping linux-kernel from Cc for next time and just using the subsystem list
and maintainers, and see if that goes any better or worse.

Note that the syzbot reports themselves are still going to linux-kernel, though.

Thanks!

- Eric

Re: [PATCH v7 0/7] Solve postboot supplier cleanup and optimize probe ordering

[Frank Rowand]

Hi Greg, Rob,

On 7/26/19 7:32 AM, Greg Kroah-Hartman wrote:
> On Thu, Jul 25, 2019 at 02:04:23PM -0700, Frank Rowand wrote:
>> On 7/25/19 6:42 AM, Greg Kroah-Hartman wrote:
>>> On Tue, Jul 23, 2019 at 05:10:53PM -0700, Saravana Kannan wrote:
 Add device-links to track functional dependencies between devices
 after they are created (but before they are probed) by looking at
 their common DT bindings like clocks, interconnects, etc.

 Having functional dependencies automatically added before the devices
 are probed, provides the following benefits:

 - Optimizes device probe order and avoids the useless work of
   attempting probes of devices that will not probe successfully
   (because their suppliers aren't present or haven't probed yet).

   For example, in a commonly available mobile SoC, registering just
   one consumer device's driver at an initcall level earlier than the
   supplier device's driver causes 11 failed probe attempts before the
   consumer device probes successfully. This was with a kernel with all
   the drivers statically compiled in. This problem gets a lot worse if
   all the drivers are loaded as modules without direct symbol
   dependencies.

 - Supplier devices like clock providers, interconnect providers, etc
   need to keep the resources they provide active and at a particular
   state(s) during boot up even if their current set of consumers don't
   request the resource to be active. This is because the rest of the
   consumers might not have probed yet and turning off the resource
   before all the consumers have probed could lead to a hang or
   undesired user experience.

   Some frameworks (Eg: regulator) handle this today by turning off
   "unused" resources at late_initcall_sync and hoping all the devices
   have probed by then. This is not a valid assumption for systems with
   loadable modules. Other frameworks (Eg: clock) just don't handle
   this due to the lack of a clear signal for when they can turn off
   resources. This leads to downstream hacks to handle cases like this
   that can easily be solved in the upstream kernel.

   By linking devices before they are probed, we give suppliers a clear
   count of the number of dependent consumers. Once all of the
   consumers are active, the suppliers can turn off the unused
   resources without making assumptions about the number of consumers.

 By default we just add device-links to track "driver presence" (probe
 succeeded) of the supplier device. If any other functionality provided
 by device-links are needed, it is left to the consumer/supplier
 devices to change the link when they probe.

 v1 -> v2:
 - Drop patch to speed up of_find_device_by_node()
 - Drop depends-on property and use existing bindings

 v2 -> v3:
 - Refactor the code to have driver core initiate the linking of devs
 - Have driver core link consumers to supplier before it's probed
 - Add support for drivers to edit the device links before probing

 v3 -> v4:
 - Tested edit_links() on system with cyclic dependency. Works.
 - Added some checks to make sure device link isn't attempted from
   parent device node to child device node.
 - Added way to pause/resume sync_state callbacks across
   of_platform_populate().
 - Recursively parse DT node to create device links from parent to
   suppliers of parent and all child nodes.

 v4 -> v5:
 - Fixed copy-pasta bugs with linked list handling
 - Walk up the phandle reference till I find an actual device (needed
   for regulators to work)
 - Added support for linking devices from regulator DT bindings
 - Tested the whole series again to make sure cyclic dependencies are
   broken with edit_links() and regulator links are created properly.

 v5 -> v6:
 - Split, squashed and reordered some of the patches.
 - Refactored the device linking code to follow the same code pattern for
   any property.

 v6 -> v7:
 - No functional changes.
 - Renamed i to index
 - Added comment to clarify not having to check property name for every
   index
 - Added "matched" variable to clarify code. No functional change.
 - Added comments to include/linux/device.h for add_links()

 I've also not updated this patch series to handle the new patch [1] from
 Rafael. Will do that once this patch series is close to being Acked.

 [1] - https://lore.kernel.org/lkml/3121545.4lOhFoIcdQ@kreacher/
>>>
>>>
>>> This looks sane to me.  Anyone have any objections for me queueing this
>>> up for my tree to get into linux-next now?
>>
>> I would like for the series to get into linux-next sooner than later,
>> and spend some time there.  
> 
> Ok, care to give me an ack for it?  :)

Rob opined to me that 

Re: [PATCH v2 0/5] Allocate memmap from hotadded memory

[Rashmica Gupta]

On Mon, 2019-07-29 at 10:06 +0200, David Hildenbrand wrote:
> > > Of course, other interfaces might make sense.
> > > 
> > > You can then start using these memory blocks and hinder them from
> > > getting onlined (as a safety net) via memory notifiers.
> > > 
> > > That would at least avoid you having to call
> > > add_memory/remove_memory/offline_pages/device_online/modifying
> > > memblock
> > > states manually.
> > 
> > I see what you're saying and that definitely sounds safer.
> > 
> > We would still need to call remove_memory and add_memory from
> > memtrace
> > as
> > just offlining memory doesn't remove it from the linear page tables
> > (if 
> > it's still in the page tables then hardware can prefetch it and if
> > hardware tracing is using it then the box checkstops).
> 
> That prefetching part is interesting (and nasty as well). If we could
> at
> least get rid of the manual onlining/offlining, I would be able to
> sleep
> better at night ;) One step at a time.
> 

What are your thoughts on adding remove to state_store in
drivers/base/memory.c? And an accompanying add? So then userspace could
do "echo remove > memory34/state"? 

Then most of the memtrace code could be moved to a userspace tool. The
only bit that we would need to keep in the kernel is setting up debugfs
files in memtrace_init_debugfs.

Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S

[Tao Ren]

On 7/30/19 6:36 PM, Andrew Lunn wrote:
>> The INTF_SEL pins report correct mode (RGMII-Fiber) on my machine,
>> but there are 2 "sub-modes" (1000Base-X and 100Base-FX) and I
>> couldn't find a proper/safe way to auto-detect which "sub-mode" is
>> active. The datasheet just describes instructions to enable a
>> specific mode, but it doesn't say 1000Base-X/100Base-FX mode will be
>> auto-selected. And that's why I came up with the patch to specify
>> 1000Base-X mode.
> 
> Fibre does not perform any sort of auto-negotiation. I assume you have
> an SFP connected? When using PHYLINK, the sfp driver will get the
> supported baud rate from SFP EEPROM to determine what speed could be
> used. However, there is currently no mainline support for having a
> chain MAC-PHY-SFP. For that you need Russells out of tree patches.

Hi Andrew,

The BCM54616S PHY on my machine is connected to a BCM5396 switch chip over 
backplane (1000Base-KX).


Thanks,

Tao

Re: [PATCH 19/24] tty: serial: fsl_lpuart: Introduce lpuart_tx_dma_startup()

[Andrey Smirnov]

On Tue, Jul 30, 2019 at 8:56 AM Greg Kroah-Hartman
 wrote:
>
> On Mon, Jul 29, 2019 at 12:52:21PM -0700, Andrey Smirnov wrote:
> > Code configure DMA TX path in lpuart_startup(), lpuart32_startup() and
> > lpuart_resume() is doing exactly the same thing, so move it into a
> > standalone subroutine.
> >
> > Signed-off-by: Andrey Smirnov 
> > Cc: Stefan Agner 
> > Cc: Bhuvanchandra DV 
> > Cc: Chris Healy 
> > Cc: Cory Tusar 
> > Cc: Lucas Stach 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-...@nxp.com
> > Cc: linux-ser...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/tty/serial/fsl_lpuart.c | 53 ++---
> >  1 file changed, 23 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/tty/serial/fsl_lpuart.c 
> > b/drivers/tty/serial/fsl_lpuart.c
> > index 2ad5750fe511..558acf29cbed 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -1434,6 +1434,26 @@ static void rx_dma_timer_init(struct lpuart_port 
> > *sport)
> >   add_timer(>lpuart_timer);
> >  }
> >
> > +static void lpuart_tx_dma_startup(struct lpuart_port *sport)
> > +{
> > + u32 uartbaud;
> > +
> > + if (sport->dma_tx_chan && !lpuart_dma_tx_request(>port)) {
> > + init_waitqueue_head(>dma_wait);
> > + sport->lpuart_dma_tx_use = true;
> > + if (lpuart_is_32(sport)) {
> > + uartbaud = lpuart32_read(>port, UARTBAUD);
> > + lpuart32_write(>port,
> > +uartbaud | UARTBAUD_TDMAE, UARTBAUD);
> > + } else {
> > + writeb(readb(sport->port.membase + UARTCR5) |
> > + UARTCR5_TDMAS, sport->port.membase + UARTCR5);
> > + }
> > + } else {
> > + sport->lpuart_dma_tx_use = false;
> > + }
> > +}
> > +
> >  static int lpuart_startup(struct uart_port *port)
> >  {
> >   struct lpuart_port *sport = container_of(port, struct lpuart_port, 
> > port);
> > @@ -1471,14 +1491,7 @@ static int lpuart_startup(struct uart_port *port)
> >   sport->lpuart_dma_rx_use = false;
> >   }
> >
> > - if (sport->dma_tx_chan && !lpuart_dma_tx_request(port)) {
> > - init_waitqueue_head(>dma_wait);
> > - sport->lpuart_dma_tx_use = true;
> > - temp = readb(port->membase + UARTCR5);
> > - writeb(temp | UARTCR5_TDMAS, port->membase + UARTCR5);
> > - } else {
> > - sport->lpuart_dma_tx_use = false;
> > - }
> > + lpuart_tx_dma_startup(port);
> >
> >   spin_unlock_irqrestore(>port.lock, flags);
> >
> > @@ -1522,14 +1535,7 @@ static int lpuart32_startup(struct uart_port *port)
> >   sport->lpuart_dma_rx_use = false;
> >   }
> >
> > - if (sport->dma_tx_chan && !lpuart_dma_tx_request(port)) {
> > - init_waitqueue_head(>dma_wait);
> > - sport->lpuart_dma_tx_use = true;
> > - temp = lpuart32_read(>port, UARTBAUD);
> > - lpuart32_write(>port, temp | UARTBAUD_TDMAE, UARTBAUD);
> > - } else {
> > - sport->lpuart_dma_tx_use = false;
> > - }
> > + lpuart_tx_dma_startup(port);
> >
> >   if (sport->lpuart_dma_rx_use) {
> >   /* RXWATER must be 0 */
> > @@ -2581,20 +2587,7 @@ static int lpuart_resume(struct device *dev)
> >   }
> >   }
> >
> > - if (sport->dma_tx_chan && !lpuart_dma_tx_request(>port)) {
> > - init_waitqueue_head(>dma_wait);
> > - sport->lpuart_dma_tx_use = true;
> > - if (lpuart_is_32(sport)) {
> > - temp = lpuart32_read(>port, UARTBAUD);
> > - lpuart32_write(>port,
> > -temp | UARTBAUD_TDMAE, UARTBAUD);
> > - } else {
> > - writeb(readb(sport->port.membase + UARTCR5) |
> > - UARTCR5_TDMAS, sport->port.membase + UARTCR5);
> > - }
> > - } else {
> > - sport->lpuart_dma_tx_use = false;
> > - }
> > + lpuart_tx_dma_startup(sport);
> >
> >   if (lpuart_is_32(sport)) {
> >   if (sport->lpuart_dma_rx_use) {
> > --
> > 2.21.0
> >
>
> This patch breaks the build:
>
> drivers/tty/serial/fsl_lpuart.c: In function lpuart_startup:
> drivers/tty/serial/fsl_lpuart.c:1494:24: error: passing argument 1 of 
> lpuart_tx_dma_startup from incompatible pointer type 
> [-Werror=incompatible-pointer-types]
>  1494 |  lpuart_tx_dma_startup(port);
>   |^~~~
>   ||
>   |struct uart_port *
> drivers/tty/serial/fsl_lpuart.c:1438:55: note: expected struct lpuart_port * 
> but argument is of type struct uart_port *
>  1438 | static void lpuart_tx_dma_startup(struct lpuart_port *sport)
>   |   ^
> 

Re: [PATCH 06/24] tty: serial: fsl_lpuart: Drop unnecessary sg_set_buf() call

[Andrey Smirnov]

On Tue, Jul 30, 2019 at 8:51 AM Greg Kroah-Hartman
 wrote:
>
> On Mon, Jul 29, 2019 at 12:52:08PM -0700, Andrey Smirnov wrote:
> > Sg_init_one() will already call sg_set_buf(), so another explicit call
> > right after it is unnecessary. Drop it.
> >
> > Signed-off-by: Andrey Smirnov 
> > Cc: Stefan Agner 
> > Cc: Bhuvanchandra DV 
> > Cc: Chris Healy 
> > Cc: Cory Tusar 
> > Cc: Lucas Stach 
> > Cc: Greg Kroah-Hartman 
> > Cc: Jiri Slaby 
> > Cc: linux-...@nxp.com
> > Cc: linux-ser...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> >  drivers/tty/serial/fsl_lpuart.c | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/tty/serial/fsl_lpuart.c 
> > b/drivers/tty/serial/fsl_lpuart.c
> > index 1b3f2a87e558..b600f591c8c2 100644
> > --- a/drivers/tty/serial/fsl_lpuart.c
> > +++ b/drivers/tty/serial/fsl_lpuart.c
> > @@ -1144,7 +1144,6 @@ static inline int lpuart_start_rx_dma(struct 
> > lpuart_port *sport)
> >   return -ENOMEM;
> >
> >   sg_init_one(>rx_sgl, ring->buf, sport->rx_dma_rng_buf_len);
> > - sg_set_buf(>rx_sgl, ring->buf, sport->rx_dma_rng_buf_len);
> >   nent = dma_map_sg(sport->port.dev, >rx_sgl, 1, 
> > DMA_FROM_DEVICE);
> >
> >   if (!nent) {
>
> This patch doesn't apply, is it already in the tree from someone else?
>

Yeah, looks like d9aa9ab4fe6b5c43b9ccb8a0811dadcfe40ea27f from your
tty tree already covered this and I didn't have it in my tree. Will
drop in v2.

Thanks,
Andrey Smirnov

Re: [PATCH v2 07/10] powerpc/fsl_booke/32: randomize the kernel image offset

[Jason Yan]

On 2019/7/30 17:44, Christophe Leroy wrote:



Le 30/07/2019 à 09:42, Jason Yan a écrit :

After we have the basic support of relocate the kernel in some
appropriate place, we can start to randomize the offset now.

Entropy is derived from the banner and timer, which will change every
build and boot. This not so much safe so additionally the bootloader may
pass entropy via the /chosen/kaslr-seed node in device tree.

We will use the first 512M of the low memory to randomize the kernel
image. The memory will be split in 64M zones. We will use the lower 8
bit of the entropy to decide the index of the 64M zone. Then we chose a
16K aligned offset inside the 64M zone to put the kernel in.

 KERNELBASE

 |-->   64M   <--|
 |   |
 +---+    ++---+
 |   ||    |kernel|    |   |
 +---+    ++---+
 | |
 |->   offset    <-|

   kimage_vaddr

We also check if we will overlap with some areas like the dtb area, the
initrd area or the crashkernel area. If we cannot find a proper area,
kaslr will be disabled and boot from the original kernel.

Signed-off-by: Jason Yan 
Cc: Diana Craciun 
Cc: Michael Ellerman 
Cc: Christophe Leroy 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Nicholas Piggin 
Cc: Kees Cook 
---
  arch/powerpc/kernel/kaslr_booke.c | 334 +-
  1 file changed, 332 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/kaslr_booke.c 
b/arch/powerpc/kernel/kaslr_booke.c

index 960bce4aa8b9..0bb02e45b928 100644
--- a/arch/powerpc/kernel/kaslr_booke.c
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -23,6 +23,8 @@
  #include 
  #include 
  #include 
+#include 
+#include 
  #include 
  #include 
  #include 
@@ -34,15 +36,341 @@
  #include 
  #include 
  #include 
+#include 
  #include 
+#include 
+#include 
+
+#ifdef DEBUG
+#define DBG(fmt...) printk(KERN_ERR fmt)
+#else
+#define DBG(fmt...)
+#endif
+
+struct regions {
+    unsigned long pa_start;
+    unsigned long pa_end;
+    unsigned long kernel_size;
+    unsigned long dtb_start;
+    unsigned long dtb_end;
+    unsigned long initrd_start;
+    unsigned long initrd_end;
+    unsigned long crash_start;
+    unsigned long crash_end;
+    int reserved_mem;
+    int reserved_mem_addr_cells;
+    int reserved_mem_size_cells;
+};
  extern int is_second_reloc;
+/* Simplified build-specific string for starting entropy. */
+static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@"
+    LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION;
+
+static __init void kaslr_get_cmdline(void *fdt)
+{
+    const char *cmdline = CONFIG_CMDLINE;
+    if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
+    int node;
+    const u8 *prop;
+    node = fdt_path_offset(fdt, "/chosen");
+    if (node < 0)
+    goto out;
+
+    prop = fdt_getprop(fdt, node, "bootargs", NULL);
+    if (!prop)
+    goto out;
+    cmdline = prop;
+    }
+out:
+    strscpy(boot_command_line, cmdline, COMMAND_LINE_SIZE);


boot_command_line is set by early_init_devtree() in 
arch/powerpc/kernel/prom.c

Is that too late for you ?



Yes, it's too late.


If so, what about calling early_init_dt_scan_chosen() instead of recoding ?



Good suggestion. I will have a try.


Christophe

.

Re: [PATCH v2 06/10] powerpc/fsl_booke/32: implement KASLR infrastructure

[Jason Yan]

On 2019/7/30 17:34, Christophe Leroy wrote:



Le 30/07/2019 à 09:42, Jason Yan a écrit :

This patch add support to boot kernel from places other than KERNELBASE.
Since CONFIG_RELOCATABLE has already supported, what we need to do is
map or copy kernel to a proper place and relocate. Freescale Book-E
parts expect lowmem to be mapped by fixed TLB entries(TLB1). The TLB1
entries are not suitable to map the kernel directly in a randomized
region, so we chose to copy the kernel to a proper place and restart to
relocate.

The offset of the kernel was not randomized yet(a fixed 64M is set). We
will randomize it in the next patch.

Signed-off-by: Jason Yan 
Cc: Diana Craciun 
Cc: Michael Ellerman 
Cc: Christophe Leroy 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Nicholas Piggin 
Cc: Kees Cook 
---
  arch/powerpc/Kconfig  | 11 +++
  arch/powerpc/kernel/Makefile  |  1 +
  arch/powerpc/kernel/early_32.c    |  2 +-
  arch/powerpc/kernel/fsl_booke_entry_mapping.S | 13 ++-
  arch/powerpc/kernel/head_fsl_booke.S  | 15 +++-
  arch/powerpc/kernel/kaslr_booke.c | 84 +++
  arch/powerpc/mm/mmu_decl.h    |  6 ++
  arch/powerpc/mm/nohash/fsl_booke.c    |  7 +-
  8 files changed, 126 insertions(+), 13 deletions(-)
  create mode 100644 arch/powerpc/kernel/kaslr_booke.c



[...]

diff --git a/arch/powerpc/kernel/head_fsl_booke.S 
b/arch/powerpc/kernel/head_fsl_booke.S

index 2083382dd662..a466c0f0d028 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -155,6 +155,8 @@ _ENTRY(_start);
   */
  _ENTRY(__early_start)
+    LOAD_REG_ADDR_PIC(r20, kimage_vaddr)
+    lwz r20,0(r20)
  #define ENTRY_MAPPING_BOOT_SETUP
  #include "fsl_booke_entry_mapping.S"
@@ -277,8 +279,8 @@ set_ivor:
  ori    r6, r6, swapper_pg_dir@l
  lis    r5, abatron_pteptrs@h
  ori    r5, r5, abatron_pteptrs@l
-    lis    r4, KERNELBASE@h
-    ori    r4, r4, KERNELBASE@l
+    lis r3, kimage_vaddr@ha
+    lwz r4, kimage_vaddr@l(r3)
  stw    r5, 0(r4)    /* Save abatron_pteptrs at a fixed location */
  stw    r6, 0(r5)
@@ -1067,7 +1069,14 @@ __secondary_start:
  mr    r5,r25    /* phys kernel start */
  rlwinm    r5,r5,0,~0x3ff    /* aligned 64M */
  subf    r4,r5,r4    /* memstart_addr - phys kernel start */
-    li    r5,0    /* no device tree */
+#ifdef CONFIG_RANDOMIZE_BASE


Is that #ifdef really necessary ? Wouldn't it also work as expected when 
CONFIG_RANDOMIZE_BASE is not selected ?




Yes, it will also work if CONFIG_RANDOMIZE_BASE is not enabled. I can 
remove it.



+    lis    r7,KERNELBASE@h
+    ori    r7,r7,KERNELBASE@l
+    cmpw    r20,r7    /* if kimage_vaddr != KERNELBASE, 
randomized */

+    beq    2f
+    li    r4,0
+#endif
+2:    li    r5,0    /* no device tree */
  li    r6,0    /* not boot cpu */
  bl    restore_to_as0
diff --git a/arch/powerpc/kernel/kaslr_booke.c 
b/arch/powerpc/kernel/kaslr_booke.c

new file mode 100644
index ..960bce4aa8b9
--- /dev/null
+++ b/arch/powerpc/kernel/kaslr_booke.c
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2019 Jason Yan 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+extern int is_second_reloc;


Couldn't the above be a bool ?



This variable is both used in C and assembly. Use int make it more 
explicit to compare it with 0 or 1 in assembly.



+
+static unsigned long __init kaslr_choose_location(void *dt_ptr, 
phys_addr_t size,

+  unsigned long kernel_sz)
+{
+    /* return a fixed offset of 64M for now */
+    return 0x400;


64 << 20 would maybe be more explicit than 0x400.

Or return SZ_64M ?



SZ_64M would be good.


Christophe


+}
+
+/*
+ * To see if we need to relocate the kernel to a random offset
+ * void *dt_ptr - address of the device tree
+ * phys_addr_t size - size of the first memory block
+ */
+notrace void __init kaslr_early_init(void *dt_ptr, phys_addr_t size)
+{
+    unsigned long tlb_virt;
+    phys_addr_t tlb_phys;
+    unsigned long offset;
+    unsigned long kernel_sz;
+
+    kernel_sz = (unsigned long)_end - KERNELBASE;
+
+    offset = kaslr_choose_location(dt_ptr, size, kernel_sz);
+
+    if (offset == 0)
+    return;
+
+    kimage_vaddr += offset;
+    kernstart_addr += offset;
+
+    is_second_reloc = 1;
+
+    if (offset >= SZ_64M) {
+    tlb_virt = round_down(kimage_vaddr, SZ_64M);
+    

Re: [RFC PATCH 13/16] RISC-V: KVM: Add timer functionality

[Atish Patra]

On Tue, 2019-07-30 at 13:26 +0200, Paolo Bonzini wrote:
> On 29/07/19 13:57, Anup Patel wrote:
> > +   if (delta_ns > VCPU_TIMER_PROGRAM_THRESHOLD_NS) {
> > +   hrtimer_start(>hrt, ktime_add_ns(ktime_get(),
> > delta_ns),
> 
> I think the guest would prefer if you saved the time before enabling
> interrupts on the host, and use that here instead of ktime_get().
> Otherwise the timer could be delayed arbitrarily by host interrupts.
> 
> (Because the RISC-V SBI timer is relative only---which is
> unfortunate---

Just to clarify: RISC-V SBI timer call passes absolute time.

https://elixir.bootlin.com/linux/v5.3-rc2/source/drivers/clocksource/timer-riscv.c#L32

That's why we compute a delta between absolute time passed via SBI and
current time. hrtimer is programmed to trigger only after the delta
time from now.


> guests will already pay a latency price due to the extra
> cost of the SBI call compared to a bare metal implementation. 

Yes. There are ongoing discussions to remove this SBI call completely. 
Hopefully, that will happen before any real hardware with
virtualization support shows up :).

>  Sooner or
> later you may want to implement something like x86's heuristic to
> advance the timer deadline by a few hundred nanoseconds; perhaps add
> a
> TODO now).
> 

I am not aware of this approach. I will take a look. Thanks.

Regards,
Atish
> Paolo
> 
> > +   HRTIMER_MODE_ABS);
> > +   t->is_set = true;
> > +   } else
> > +   kvm_riscv_vcpu_set_interrupt(vcpu, IRQ_S_TIMER);
> > +
> 
> ___
> linux-riscv mailing list
> linux-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv

[PATCH net v3] net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address

[Su Yanjun]

When the egress interface does not have a link local address, it can
not communicate with other hosts.

In RFC4861, 7.2.2 says
"If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that
address SHOULD be placed in the IP Source Address of the outgoing
solicitation.  Otherwise, any one of the addresses assigned to the
interface should be used."

In this patch we try get a global address if we get ll address failed.

Signed-off-by: Su Yanjun 
---
Changes since V2:
- Let banned_flags under the scope of its use.
---
 include/net/addrconf.h |  2 ++
 net/ipv6/addrconf.c| 34 ++
 net/ipv6/ndisc.c   | 10 +++---
 3 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/include/net/addrconf.h b/include/net/addrconf.h
index 269ec27..eae1167 100644
--- a/include/net/addrconf.h
+++ b/include/net/addrconf.h
@@ -107,6 +107,8 @@ int __ipv6_get_lladdr(struct inet6_dev *idev, struct 
in6_addr *addr,
  u32 banned_flags);
 int ipv6_get_lladdr(struct net_device *dev, struct in6_addr *addr,
u32 banned_flags);
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+   u32 banned_flags);
 bool inet_rcv_saddr_equal(const struct sock *sk, const struct sock *sk2,
  bool match_wildcard);
 bool inet_rcv_saddr_any(const struct sock *sk);
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 4ae17a9..9e537bd 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1873,6 +1873,40 @@ int ipv6_get_lladdr(struct net_device *dev, struct 
in6_addr *addr,
return err;
 }
 
+int __ipv6_get_addr(struct inet6_dev *idev, struct in6_addr *addr,
+   u32 banned_flags)
+{
+   struct inet6_ifaddr *ifp;
+   int err = -EADDRNOTAVAIL;
+
+   list_for_each_entry(ifp, >addr_list, if_list) {
+   if (ifp->scope == 0 &&
+   !(ifp->flags & banned_flags)) {
+   *addr = ifp->addr;
+   err = 0;
+   break;
+   }
+   }
+   return err;
+}
+
+int ipv6_get_addr(struct net_device *dev, struct in6_addr *addr,
+ u32 banned_flags)
+{
+   struct inet6_dev *idev;
+   int err = -EADDRNOTAVAIL;
+
+   rcu_read_lock();
+   idev = __in6_dev_get(dev);
+   if (idev) {
+   read_lock_bh(>lock);
+   err = __ipv6_get_addr(idev, addr, banned_flags);
+   read_unlock_bh(>lock);
+   }
+   rcu_read_unlock();
+   return err;
+}
+
 static int ipv6_count_addresses(const struct inet6_dev *idev)
 {
const struct inet6_ifaddr *ifp;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 659ecf4e..fa58c6e 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -592,9 +592,13 @@ void ndisc_send_ns(struct net_device *dev, const struct 
in6_addr *solicit,
struct nd_msg *msg;
 
if (!saddr) {
-   if (ipv6_get_lladdr(dev, _buf,
-  (IFA_F_TENTATIVE|IFA_F_OPTIMISTIC)))
-   return;
+   u32 banned_flags = IFA_F_TENTATIVE | IFA_F_OPTIMISTIC;
+
+   if (ipv6_get_lladdr(dev, _buf, banned_flags)) {
+   /* try global address */
+   if (ipv6_get_addr(dev, _buf, banned_flags))
+   return;
+   }
saddr = _buf;
}
 
-- 
2.7.4

Re: [PATCH bpf-next v10 10/10] landlock: Add user and kernel documentation for Landlock

[Randy Dunlap]

On 7/21/19 2:31 PM, Mickaël Salaün wrote:
> This documentation can be built with the Sphinx framework.
> 
> Signed-off-by: Mickaël Salaün 
> Cc: Alexei Starovoitov 
> Cc: Andy Lutomirski 
> Cc: Daniel Borkmann 
> Cc: David S. Miller 
> Cc: James Morris 
> Cc: Jonathan Corbet 
> Cc: Kees Cook 
> Cc: Serge E. Hallyn 
> ---
> 
> Changes since v9:
> * update with expected attach type and expected attach triggers
> 
> Changes since v8:
> * remove documentation related to chaining and tagging according to this
>   patch series
> 
> Changes since v7:
> * update documentation according to the Landlock revamp
> 
> Changes since v6:
> * add a check for ctx->event
> * rename BPF_PROG_TYPE_LANDLOCK to BPF_PROG_TYPE_LANDLOCK_RULE
> * rename Landlock version to ABI to better reflect its purpose and add a
>   dedicated changelog section
> * update tables
> * relax no_new_privs recommendations
> * remove ABILITY_WRITE related functions
> * reword rule "appending" to "prepending" and explain it
> * cosmetic fixes
> 
> Changes since v5:
> * update the rule hierarchy inheritance explanation
> * briefly explain ctx->arg2
> * add ptrace restrictions
> * explain EPERM
> * update example (subtype)
> * use ":manpage:"
> ---
>  Documentation/security/index.rst   |   1 +
>  Documentation/security/landlock/index.rst  |  20 +++
>  Documentation/security/landlock/kernel.rst |  99 ++
>  Documentation/security/landlock/user.rst   | 147 +
>  4 files changed, 267 insertions(+)
>  create mode 100644 Documentation/security/landlock/index.rst
>  create mode 100644 Documentation/security/landlock/kernel.rst
>  create mode 100644 Documentation/security/landlock/user.rst


> diff --git a/Documentation/security/landlock/kernel.rst 
> b/Documentation/security/landlock/kernel.rst
> new file mode 100644
> index ..7d1e06d544bf
> --- /dev/null
> +++ b/Documentation/security/landlock/kernel.rst
> @@ -0,0 +1,99 @@
> +==
> +Landlock: kernel documentation
> +==
> +
> +eBPF properties
> +===
> +
> +To get an expressive language while still being safe and small, Landlock is
> +based on eBPF. Landlock should be usable by untrusted processes and must
> +therefore expose a minimal attack surface. The eBPF bytecode is minimal,
> +powerful, widely used and designed to be used by untrusted applications. 
> Thus,
> +reusing the eBPF support in the kernel enables a generic approach while
> +minimizing new code.
> +
> +An eBPF program has access to an eBPF context containing some fields used to
> +inspect the current object. These arguments can be used directly (e.g. 
> cookie)
> +or passed to helper functions according to their types (e.g. inode pointer). 
> It
> +is then possible to do complex access checks without race conditions or
> +inconsistent evaluation (i.e.  `incorrect mirroring of the OS code and state
> +`_).
> +
> +A Landlock hook describes a particular access type.  For now, there is two

 there are two

> +hooks dedicated to filesystem related operations: LANDLOCK_HOOK_FS_PICK and
> +LANDLOCK_HOOK_FS_WALK.  A Landlock program is tied to one hook.  This makes 
> it
> +possible to statically check context accesses, potentially performed by such
> +program, and hence prevents kernel address leaks and ensure the right use of

ensures

> +hook arguments with eBPF functions.  Any user can add multiple Landlock
> +programs per Landlock hook.  They are stacked and evaluated one after the
> +other, starting from the most recent program, as seccomp-bpf does with its
> +filters.  Underneath, a hook is an abstraction over a set of LSM hooks.
> +
> +
> +Guiding principles
> +==
> +
> +Unprivileged use
> +
> +
> +* Landlock helpers and context should be usable by any unprivileged and
> +  untrusted program while following the system security policy enforced by
> +  other access control mechanisms (e.g. DAC, LSM).
> +
> +
> +Landlock hook and context
> +-
> +
> +* A Landlock hook shall be focused on access control on kernel objects 
> instead
> +  of syscall filtering (i.e. syscall arguments), which is the purpose of
> +  seccomp-bpf.
> +* A Landlock context provided by a hook shall express the minimal and more
> +  generic interface to control an access for a kernel object.
> +* A hook shall guaranty that all the BPF function calls from a program are> 
> +  safe.  Thus, the related Landlock context arguments shall always be of the
> +  same type for a particular hook.  For example, a network hook could share
> +  helpers with a file hook because of UNIX socket.  However, the same helpers
> +  may not be compatible for a file system handle and a 

[PATCH v16 0/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI driver

[Mason Yang]

Hi Mark,

v16 patch including:
1) fixed typo and spi-tx/rx-bus-width in DTS.
2) v14 dt-binding file has reviewed by Rob Herring.

v15 patch including:
1) A typo in dt-bindings and add flash subnode description
2) v14 dt-binding file has reviewed by Rob Herring.

v14 patch including:
1) Patch RPC-IF back to SPI mode only instead of MFD & SPI 
   by MFD maintainer, Lee Jones comments.
2) Patch pm_runtime control in spi transfer.

v13 patch including:
1) rename mfd to ddata for SPI driver.
2) Patch RPC-IF devicetree for SPI and HyperFlash.

v12 patch including:
1) add back "wbuf" in dts example.
2) RPC-IF replace rpc-if in dts.

v11 patch including:
1) Patch mfd include header file.
2) mfd coding style.
3) add back wbuf description in dts.

v10 patch including:
1) Address range for > 64M byte flash.
2) Removed dirmap_write due to WBUF 256 bytes transfer issue.
3) Dummy bytes setting according to spi-nor.c layer.

v9 patch is for RPC MFD driver and RPC SPI driver.

v8 patch including:
1) Supported SoC-specific values in DTS.
2) Rename device node name as flash.

v7 patch is according to Geert and Sergei's comments:
1) Add all R-Car Gen3 model in dts.
2) patch rpc-if child node search.
3) minror coding style.

v6 patch is accroding to Geert, Marek and Sergei's comments:
1) spi_controller for new code.
2) "renesas,rcar-gen3-rpc" instead of "renesas,r8a77995-rpc."
3) patch external address read mode w/o u64 readq().
4) patch dts for write buffer & drop "renesas,rpc-mode".
5) coding style and so on.

v5 patch is accroding to Sergei's comments:
1) Read 6 bytes ID from Sergei's patch.
2) regmap_update_bits().
3) C++ style comment.

v4 patch is according to Sergei's comments including:
1) Drop soc_device_match().
2) Drop unused RPC registers.
3) Use ilog2() instead of fls().
4) Patch read 6 bytes ID w/ one command.
5) Coding style and so on.

v3 patch is according to Marek and Geert's comments including:
1) soc_device_mach() to set up RPC_PHYCNT_STRTIM.
2) get_unaligned().
3) rpc-mode for rpi-spi-flash or rpc-hyperflash.
4) coding style and so on.

v2 patch including:
1) remove RPC clock enable/dis-able control,
2) patch run time PM.
3) add RPC module software reset,
4) add regmap.
5) other coding style and so on.

thanks for your review.

best regards,
Mason


Mason Yang (2):
  spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver
  dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller
bindings

 .../devicetree/bindings/spi/spi-renesas-rpc.txt|  45 ++
 drivers/spi/Kconfig|   6 +
 drivers/spi/Makefile   |   1 +
 drivers/spi/spi-renesas-rpc.c  | 754 +
 4 files changed, 806 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
 create mode 100644 drivers/spi/spi-renesas-rpc.c

-- 
1.9.1

[PATCH v16 2/2] dt-bindings: spi: Document Renesas R-Car Gen3 RPC-IF controller bindings

[Mason Yang]

Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.

Signed-off-by: Mason Yang 
Reviewed-by: Rob Herring 
---
 .../devicetree/bindings/spi/spi-renesas-rpc.txt| 45 ++
 1 file changed, 45 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt

diff --git a/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt 
b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
new file mode 100644
index 000..d4344c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-renesas-rpc.txt
@@ -0,0 +1,45 @@
+Renesas R-Car Gen3 RPC-IF controller Device Tree Bindings
+-
+
+Required properties:
+- compatible: should be an SoC-specific compatible value, followed by
+   "renesas,rcar-gen3-rpc" as a fallback.
+   supported SoC-specific values are:
+   "renesas,r8a77980-rpc"  (R-Car V3H)
+   "renesas,r8a77995-rpc"  (R-Car D3)
+- reg: should contain three register areas:
+   first for the base address of RPC-IF registers,
+   second for the direct mapping read mode and
+   third for the write buffer area.
+- reg-names: should contain "regs", "dirmap" and "wbuf"
+- clocks: should contain the clock phandle/specifier pair for the module clock.
+- clock-names: should contain "rpc"
+- power-domains: should contain the power domain phandle/secifier pair.
+- resets: should contain the reset controller phandle/specifier pair.
+- #address-cells: should be 1
+- #size-cells: should be 0
+- flash: should be represented by a subnode of the RPC-IF node,
+its "compatible" property contains "jedec,spi-nor" if SPI is used.
+
+Example:
+
+   rpc: spi@ee20 {
+   compatible = "renesas,r8a77995-rpc", "renesas,rcar-gen3-rpc";
+   reg = <0 0xee20 0 0x200>, <0 0x0800 0 0x400>,
+ <0 0xee208000 0 0x100>;
+   reg-names = "regs", "dirmap", "wbuf";
+   clocks = < CPG_MOD 917>;
+   clock-names = "rpc";
+   power-domains = < R8A77995_PD_ALWAYS_ON>;
+   resets = < 917>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <4000>;
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   };
+   };
-- 
1.9.1

[PATCH v16 1/2] spi: Add Renesas R-Car Gen3 RPC-IF SPI controller driver

[Mason Yang]

Add a driver for Renesas R-Car Gen3 RPC-IF SPI controller.

Signed-off-by: Mason Yang 
Signed-off-by: Sergei Shtylyov 
---
 drivers/spi/Kconfig   |   6 +
 drivers/spi/Makefile  |   1 +
 drivers/spi/spi-renesas-rpc.c | 754 ++
 3 files changed, 761 insertions(+)
 create mode 100644 drivers/spi/spi-renesas-rpc.c

diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 3a1d8f1..88e28de 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -571,6 +571,12 @@ config SPI_RSPI
help
  SPI driver for Renesas RSPI and QSPI blocks.
 
+config SPI_RENESAS_RPC
+   tristate "Renesas R-Car Gen3 RPC-IF SPI controller"
+   depends on ARCH_RENESAS || COMPILE_TEST
+   help
+ SPI driver for Renesas R-Car Gen3 RPC-IF.
+
 config SPI_QCOM_QSPI
tristate "QTI QSPI controller"
depends on ARCH_QCOM
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index 63dcab5..d858e4c 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -87,6 +87,7 @@ obj-$(CONFIG_SPI_QUP) += spi-qup.o
 obj-$(CONFIG_SPI_ROCKCHIP) += spi-rockchip.o
 obj-$(CONFIG_SPI_RB4XX)+= spi-rb4xx.o
 obj-$(CONFIG_SPI_RSPI) += spi-rspi.o
+obj-$(CONFIG_SPI_RENESAS_RPC)  += spi-renesas-rpc.o
 obj-$(CONFIG_SPI_S3C24XX)  += spi-s3c24xx-hw.o
 spi-s3c24xx-hw-y   := spi-s3c24xx.o
 spi-s3c24xx-hw-$(CONFIG_SPI_S3C24XX_FIQ) += spi-s3c24xx-fiq.o
diff --git a/drivers/spi/spi-renesas-rpc.c b/drivers/spi/spi-renesas-rpc.c
new file mode 100644
index 000..648d14e
--- /dev/null
+++ b/drivers/spi/spi-renesas-rpc.c
@@ -0,0 +1,754 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2018 ~ 2019 Renesas Solutions Corp.
+// Copyright (C) 2019 Macronix International Co., Ltd.
+//
+// R-Car Gen3 RPC-IF SPI/QSPI/Octa driver
+//
+// Author:
+// Mason Yang 
+//
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define RPC_CMNCR  0x  // R/W
+#define RPC_CMNCR_MD   BIT(31)
+#define RPC_CMNCR_SFDE BIT(24) // undocumented bit but must be set
+#define RPC_CMNCR_MOIIO3(val)  (((val) & 0x3) << 22)
+#define RPC_CMNCR_MOIIO2(val)  (((val) & 0x3) << 20)
+#define RPC_CMNCR_MOIIO1(val)  (((val) & 0x3) << 18)
+#define RPC_CMNCR_MOIIO0(val)  (((val) & 0x3) << 16)
+#define RPC_CMNCR_MOIIO_HIZ(RPC_CMNCR_MOIIO0(3) | RPC_CMNCR_MOIIO1(3) | \
+RPC_CMNCR_MOIIO2(3) | RPC_CMNCR_MOIIO3(3))
+#define RPC_CMNCR_IO3FV(val)   (((val) & 0x3) << 14) // undocumented
+#define RPC_CMNCR_IO2FV(val)   (((val) & 0x3) << 12) // undocumented
+#define RPC_CMNCR_IO0FV(val)   (((val) & 0x3) << 8)
+#define RPC_CMNCR_IOFV_HIZ (RPC_CMNCR_IO0FV(3) | RPC_CMNCR_IO2FV(3) | \
+RPC_CMNCR_IO3FV(3))
+#define RPC_CMNCR_BSZ(val) (((val) & 0x3) << 0)
+
+#define RPC_SSLDR  0x0004  // R/W
+#define RPC_SSLDR_SPNDL(d) (((d) & 0x7) << 16)
+#define RPC_SSLDR_SLNDL(d) (((d) & 0x7) << 8)
+#define RPC_SSLDR_SCKDL(d) (((d) & 0x7) << 0)
+
+#define RPC_DRCR   0x000C  // R/W
+#define RPC_DRCR_SSLN  BIT(24)
+#define RPC_DRCR_RBURST(v) v) - 1) & 0x1F) << 16)
+#define RPC_DRCR_RCF   BIT(9)
+#define RPC_DRCR_RBE   BIT(8)
+#define RPC_DRCR_SSLE  BIT(0)
+
+#define RPC_DRCMR  0x0010  // R/W
+#define RPC_DRCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_DRCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_DREAR  0x0014  // R/W
+#define RPC_DREAR_EAV(c)   (((c) & 0xf) << 16)
+#define RPC_DREAR_EAC(c)   (((c) & 0x7) << 0)
+
+#define RPC_DROPR  0x0018  // R/W
+
+#define RPC_DRENR  0x001C  // R/W
+#define RPC_DRENR_CDB(o)   (u32)o) & 0x3) << 30))
+#define RPC_DRENR_OCDB(o)  (((o) & 0x3) << 28)
+#define RPC_DRENR_ADB(o)   (((o) & 0x3) << 24)
+#define RPC_DRENR_OPDB(o)  (((o) & 0x3) << 20)
+#define RPC_DRENR_DRDB(o)  (((o) & 0x3) << 16)
+#define RPC_DRENR_DME  BIT(15)
+#define RPC_DRENR_CDE  BIT(14)
+#define RPC_DRENR_OCDE BIT(12)
+#define RPC_DRENR_ADE(v)   (((v) & 0xF) << 8)
+#define RPC_DRENR_OPDE(v)  (((v) & 0xF) << 4)
+
+#define RPC_SMCR   0x0020  // R/W
+#define RPC_SMCR_SSLKP BIT(8)
+#define RPC_SMCR_SPIRE BIT(2)
+#define RPC_SMCR_SPIWE BIT(1)
+#define RPC_SMCR_SPIE  BIT(0)
+
+#define RPC_SMCMR  0x0024  // R/W
+#define RPC_SMCMR_CMD(c)   (((c) & 0xFF) << 16)
+#define RPC_SMCMR_OCMD(c)  (((c) & 0xFF) << 0)
+
+#define RPC_SMADR  0x0028  // R/W
+#define RPC_SMOPR  0x002C  // R/W
+#define RPC_SMOPR_OPD3(o)  (((o) & 0xFF) << 24)
+#define RPC_SMOPR_OPD2(o)  (((o) & 0xFF) << 16)
+#define RPC_SMOPR_OPD1(o)  (((o) & 0xFF) << 8)
+#define 

Re: [PATCH] tracefs: Restrict tracefs when the kernel is locked down

[Steven Rostedt]

On Tue, 30 Jul 2019 11:47:34 -0700
Matthew Garrett  wrote:

> Tracefs may release more information about the kernel than desirable, so
> restrict it when the kernel is locked down in confidentiality mode by
> preventing open().
> 
> Signed-off-by: Matthew Garrett 
> Cc: Steven Rostedt 

Reviewed-by: Steven Rostedt (VMware) 

-- Steve

Re: [PATCH] scsi: ibmvfc: Mark expected switch fall-throughs

[Tyrel Datwyler]

On 7/28/19 5:26 PM, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
> 
> This patch fixes the following warnings:
> 
> drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_npiv_login_done':
> drivers/scsi/ibmvscsi/ibmvfc.c:4022:3: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>ibmvfc_retry_host_init(vhost);
>^
> drivers/scsi/ibmvscsi/ibmvfc.c:4023:2: note: here
>   case IBMVFC_MAD_DRIVER_FAILED:
>   ^~~~
> drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_bsg_request':
> drivers/scsi/ibmvscsi/ibmvfc.c:1830:11: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>port_id = (bsg_request->rqst_data.h_els.port_id[0] << 16) |
>^~~
> (bsg_request->rqst_data.h_els.port_id[1] << 8) |
> 
> bsg_request->rqst_data.h_els.port_id[2];
> ~~~
> drivers/scsi/ibmvscsi/ibmvfc.c:1833:2: note: here
>   case FC_BSG_RPT_ELS:
>   ^~~~
> drivers/scsi/ibmvscsi/ibmvfc.c:1838:11: warning: this statement may fall 
> through [-Wimplicit-fallthrough=]
>port_id = (bsg_request->rqst_data.h_ct.port_id[0] << 16) |
>^~
> (bsg_request->rqst_data.h_ct.port_id[1] << 8) |
> ~~~
> bsg_request->rqst_data.h_ct.port_id[2];
> ~~
> drivers/scsi/ibmvscsi/ibmvfc.c:1841:2: note: here
>   case FC_BSG_RPT_CT:
>   ^~~~
> 
> Reported-by: Stephen Rothwell 
> Signed-off-by: Gustavo A. R. Silva 
> ---

Acked-by: Tyrel Datwyler 

Re: linux-next: build warnings after merge of the keys tree

[Eric Biggers]

On Tue, Jul 30, 2019 at 01:52:16PM +1000, Stephen Rothwell wrote:
> Hi Eric,
> 
> On Mon, 29 Jul 2019 20:47:04 -0700 Eric Biggers  wrote:
> >
> > On Tue, Jul 30, 2019 at 12:30:42PM +1000, Stephen Rothwell wrote:
> > > +static struct key_acl fsverity_acl = {
> > > + .usage  = REFCOUNT_INIT(1),
> > > + .possessor_viewable = true,  
> > 
> > I don't think .possessor_viewable should be set here, since there's no
> > KEY_POSSESSOR_ACE(KEY_ACE_VIEW) in the ACL.  David, this bool is supposed to
> > mean such an entry is present, right?  Is it really necessary, since it's
> > redundant with the ACL itself?
> 
> OK, I can take that out of the patch for tomorrow.
> 
> > Otherwise this looks good, thanks Stephen.  I'll want to remove a few of 
> > these
> > permissions in a separate patch later, but for now we can just keep it
> > equivalent to the original code as you've done.
> 
> Thanks for the review.
> 

Hmm, apparently it's not *exactly* equivalent, since the ACL is missing INVAL
and JOIN permission for the owner, while those were originally granted by SEARCH
permission.  We don't need those, but just to keep the merge resolution itself
as boring as possible, can you please use the following to make it equivalent:

static struct key_acl fsverity_acl = {
.usage  = REFCOUNT_INIT(1),
.nr_ace = 2,
.aces = {
KEY_POSSESSOR_ACE(KEY_ACE_SEARCH | KEY_ACE_JOIN |
  KEY_ACE_INVAL),
KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ | KEY_ACE_WRITE |
  KEY_ACE_SEARCH | KEY_ACE_SET_SECURITY |
  KEY_ACE_INVAL | KEY_ACE_REVOKE | KEY_ACE_JOIN |
  KEY_ACE_CLEAR),
}
};


Thanks!

- Eric

Re: [PATCH net-next 2/2] net: phy: broadcom: add 1000Base-X support for BCM54616S

[Andrew Lunn]

> The INTF_SEL pins report correct mode (RGMII-Fiber) on my machine,
> but there are 2 "sub-modes" (1000Base-X and 100Base-FX) and I
> couldn't find a proper/safe way to auto-detect which "sub-mode" is
> active. The datasheet just describes instructions to enable a
> specific mode, but it doesn't say 1000Base-X/100Base-FX mode will be
> auto-selected. And that's why I came up with the patch to specify
> 1000Base-X mode.

Fibre does not perform any sort of auto-negotiation. I assume you have
an SFP connected? When using PHYLINK, the sfp driver will get the
supported baud rate from SFP EEPROM to determine what speed could be
used. However, there is currently no mainline support for having a
chain MAC-PHY-SFP. For that you need Russells out of tree patches.

  Andrew

linux-next: manual merge of the hwmon-staging tree with the mips tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the hwmon-staging tree got a conflict in:

  drivers/hwmon/jz4740-hwmon.c

between commit:

  d202742058b2 ("hwmon: Drop obsolete JZ4740 driver")

from the mips tree and commit:

  8d91bfd06bc1 ("hwmon: Remove dev_err() usage after platform_get_irq()")

from the hwmon-staging tree.

I fixed it up (I just removed the file) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.

-- 
Cheers,
Stephen Rothwell


pgpntYZbOq5Sr.pgp
Description: OpenPGP digital signature

[PATCH v2 net] hv_sock: Fix hang when a connection is closed

[Dexuan Cui]

There is a race condition for an established connection that is being closed
by the guest: the refcnt is 4 at the end of hvs_release() (Note: here the
'remove_sock' is false):

1 for the initial value;
1 for the sk being in the bound list;
1 for the sk being in the connected list;
1 for the delayed close_work.

After hvs_release() finishes, __vsock_release() -> sock_put(sk) *may*
decrease the refcnt to 3.

Concurrently, hvs_close_connection() runs in another thread:
  calls vsock_remove_sock() to decrease the refcnt by 2;
  call sock_put() to decrease the refcnt to 0, and free the sk;
  next, the "release_sock(sk)" may hang due to use-after-free.

In the above, after hvs_release() finishes, if hvs_close_connection() runs
faster than "__vsock_release() -> sock_put(sk)", then there is not any issue,
because at the beginning of hvs_close_connection(), the refcnt is still 4.

The issue can be resolved if an extra reference is taken when the
connection is established.

Fixes: a9eeb998c28d ("hv_sock: Add support for delayed close")
Signed-off-by: Dexuan Cui 
Cc: sta...@vger.kernel.org

---

Changes in v2: 
  Changed the location of the sock_hold() call. 
  Updated the changelog accordingly.
  
  Thanks Sunil for the suggestion!


With the proper kernel debugging options enabled, first a warning can
appear:

kworker/1:0/4467 is freeing memory ..., with a lock still held there!
stack backtrace:
Workqueue: events vmbus_onmessage_work [hv_vmbus]
Call Trace:
 dump_stack+0x67/0x90
 debug_check_no_locks_freed.cold.52+0x78/0x7d
 slab_free_freelist_hook+0x85/0x140
 kmem_cache_free+0xa5/0x380
 __sk_destruct+0x150/0x260
 hvs_close_connection+0x24/0x30 [hv_sock]
 vmbus_onmessage_work+0x1d/0x30 [hv_vmbus]
 process_one_work+0x241/0x600
 worker_thread+0x3c/0x390
 kthread+0x11b/0x140
 ret_from_fork+0x24/0x30

and then the following release_sock(sk) can hang:

watchdog: BUG: soft lockup - CPU#1 stuck for 22s! [kworker/1:0:4467]
...
irq event stamp: 62890
CPU: 1 PID: 4467 Comm: kworker/1:0 Tainted: GW 5.2.0+ #39
Workqueue: events vmbus_onmessage_work [hv_vmbus]
RIP: 0010:queued_spin_lock_slowpath+0x2b/0x1e0
...
Call Trace:
 do_raw_spin_lock+0xab/0xb0
 release_sock+0x19/0xb0
 vmbus_onmessage_work+0x1d/0x30 [hv_vmbus]
 process_one_work+0x241/0x600
 worker_thread+0x3c/0x390
 kthread+0x11b/0x140
 ret_from_fork+0x24/0x30

 net/vmw_vsock/hyperv_transport.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/net/vmw_vsock/hyperv_transport.c b/net/vmw_vsock/hyperv_transport.c
index f2084e3f7aa4..9d864ebeb7b3 100644
--- a/net/vmw_vsock/hyperv_transport.c
+++ b/net/vmw_vsock/hyperv_transport.c
@@ -312,6 +312,11 @@ static void hvs_close_connection(struct vmbus_channel 
*chan)
lock_sock(sk);
hvs_do_close_lock_held(vsock_sk(sk), true);
release_sock(sk);
+
+   /* Release the refcnt for the channel that's opened in
+* hvs_open_connection().
+*/
+   sock_put(sk);
 }
 
 static void hvs_open_connection(struct vmbus_channel *chan)
@@ -407,6 +412,9 @@ static void hvs_open_connection(struct vmbus_channel *chan)
}
 
set_per_channel_state(chan, conn_from_host ? new : sk);
+
+   /* This reference will be dropped by hvs_close_connection(). */
+   sock_hold(conn_from_host ? new : sk);
vmbus_set_chn_rescind_callback(chan, hvs_close_connection);
 
/* Set the pending send size to max packet size to always get
-- 
2.19.1

[PATCH v2 0/5] Miscellaneous fixes

[Atish Patra]

This patch series have some unrelated fixes related
to clocksource, dt-bindings and isa strings.

I combined them into series as most of them are
prerequisite for kvm patch series.

Changes from v1->v2:

1. Dropped the case-insensitive support patch and added a dt-bindings
   update patch.
2. Added a export symbol patch.

Anup Patel (1):
RISC-V: Add riscv_isa reprensenting ISA features common across CPUs

Atish Patra (4):
RISC-V: Remove per cpu clocksource
RISC-V: Fix unsupported isa string info.
RISC-V: Export few kernel symbols
dt-bindings: Update the isa string description

.../devicetree/bindings/riscv/cpus.yaml   |  6 ++-
arch/riscv/include/asm/hwcap.h| 25 ++
arch/riscv/kernel/cpu.c   | 47 +++
arch/riscv/kernel/cpufeature.c| 41 ++--
arch/riscv/kernel/smp.c   |  2 +-
arch/riscv/kernel/time.c  |  1 +
drivers/clocksource/timer-riscv.c |  6 +--
7 files changed, 109 insertions(+), 19 deletions(-)

--
2.21.0

[PATCH v2 3/5] RISC-V: Fix unsupported isa string info.

[Atish Patra]

Currently, kernel prints a info warning if any of the extensions
from "mafdcsu" is missing in device tree. This is not entirely
correct as Linux can boot with "f or d" extensions if kernel is
configured accordingly. Moreover, it will continue to print the
info string for future extensions such as hypervisor as well which
is misleading. /proc/cpuinfo also doesn't print any other extensions
except "mafdcsu".

Make sure that info log is only printed only if kernel is configured
to have any mandatory extensions but device tree doesn't describe it.
All the extensions present in device tree and follow the order
described in the RISC-V specification (except 'S') are printed via
/proc/cpuinfo always.

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/cpu.c | 47 -
 1 file changed, 37 insertions(+), 10 deletions(-)

diff --git a/arch/riscv/kernel/cpu.c b/arch/riscv/kernel/cpu.c
index 7da3c6a93abd..9b1d4550fbe6 100644
--- a/arch/riscv/kernel/cpu.c
+++ b/arch/riscv/kernel/cpu.c
@@ -7,6 +7,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  * Returns the hart ID of the given device tree node, or -ENODEV if the node
@@ -46,11 +47,14 @@ int riscv_of_processor_hartid(struct device_node *node)
 
 #ifdef CONFIG_PROC_FS
 
-static void print_isa(struct seq_file *f, const char *orig_isa)
+static void print_isa(struct seq_file *f, const char *orig_isa,
+ unsigned long cpuid)
 {
-   static const char *ext = "mafdcsu";
+   static const char *mandatory_ext = "mafdcsu";
const char *isa = orig_isa;
const char *e;
+   char unsupported_isa[26] = {0};
+   int index = 0;
 
/*
 * Linux doesn't support rv32e or rv128i, and we only support booting
@@ -70,27 +74,50 @@ static void print_isa(struct seq_file *f, const char 
*orig_isa)
isa += 5;
 
/*
-* Check the rest of the ISA string for valid extensions, printing those
-* we find.  RISC-V ISA strings define an order, so we only print the
+* RISC-V ISA strings define an order, so we only print all the
 * extension bits when they're in order. Hide the supervisor (S)
 * extension from userspace as it's not accessible from there.
+* Throw a warning only if any mandatory extensions are not available
+* and kernel is configured to have that mandatory extensions.
 */
-   for (e = ext; *e != '\0'; ++e) {
-   if (isa[0] == e[0]) {
+   for (e = mandatory_ext; *e != '\0'; ++e) {
+   if (isa[0] != e[0]) {
+#if defined(CONFIG_ISA_RISCV_C)
+   if (isa[0] == 'c')
+   continue;
+#endif
+#if defined(CONFIG_FP)
+   if ((isa[0] == 'f') || (isa[0] == 'd'))
+   continue;
+#endif
+   unsupported_isa[index] = e[0];
+   index++;
+   }
+   /* Only write if part of isa string */
+   if (isa[0] != '\0') {
if (isa[0] != 's')
seq_write(f, isa, 1);
-
isa++;
}
}
+   if (isa[0] != '\0') {
+   /* Add remainging isa strings */
+   for (e = isa; *e != '\0'; ++e) {
+#if !defined(CONFIG_VIRTUALIZATION)
+   if (e[0] != 'h')
+#endif
+   seq_write(f, e, 1);
+   }
+   }
seq_puts(f, "\n");
 
/*
 * If we were given an unsupported ISA in the device tree then print
 * a bit of info describing what went wrong.
 */
-   if (isa[0] != '\0')
-   pr_info("unsupported ISA \"%s\" in device tree\n", orig_isa);
+   if (unsupported_isa[0])
+   pr_info("unsupported ISA extensions \"%s\" in device tree for 
cpu [%ld]\n",
+   unsupported_isa, cpuid);
 }
 
 static void print_mmu(struct seq_file *f, const char *mmu_type)
@@ -134,7 +161,7 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "processor\t: %lu\n", cpu_id);
seq_printf(m, "hart\t\t: %lu\n", cpuid_to_hartid_map(cpu_id));
if (!of_property_read_string(node, "riscv,isa", ))
-   print_isa(m, isa);
+   print_isa(m, isa, cpu_id);
if (!of_property_read_string(node, "mmu-type", ))
print_mmu(m, mmu);
if (!of_property_read_string(node, "compatible", )
-- 
2.21.0

[PATCH v2 2/5] RISC-V: Add riscv_isa reprensenting ISA features common across CPUs

[Atish Patra]

From: Anup Patel 

This patch adds riscv_isa integer to represent ISA features common
across all CPUs. The riscv_isa is not same as elf_hwcap because
elf_hwcap will only have ISA features relevant for user-space apps
whereas riscv_isa will have ISA features relevant to both kernel
and user-space apps.

One of the use case is KVM hypervisor where riscv_isa will be used
to do following operations:

1. Check whether hypervisor extension is available
2. Find ISA features that need to be virtualized (e.g. floating
   point support, vector extension, etc.)

Signed-off-by: Anup Patel 
Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/hwcap.h | 25 +
 arch/riscv/kernel/cpufeature.c | 41 +++---
 2 files changed, 63 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
index 7ecb7c6a57b1..e069f60ad5d2 100644
--- a/arch/riscv/include/asm/hwcap.h
+++ b/arch/riscv/include/asm/hwcap.h
@@ -22,5 +22,30 @@ enum {
 };
 
 extern unsigned long elf_hwcap;
+
+#define RISCV_ISA_EXT_A(1UL << ('A' - 'A'))
+#define RISCV_ISA_EXT_aRISCV_ISA_EXT_A
+#define RISCV_ISA_EXT_C(1UL << ('C' - 'A'))
+#define RISCV_ISA_EXT_cRISCV_ISA_EXT_C
+#define RISCV_ISA_EXT_D(1UL << ('D' - 'A'))
+#define RISCV_ISA_EXT_dRISCV_ISA_EXT_D
+#define RISCV_ISA_EXT_F(1UL << ('F' - 'A'))
+#define RISCV_ISA_EXT_fRISCV_ISA_EXT_F
+#define RISCV_ISA_EXT_H(1UL << ('H' - 'A'))
+#define RISCV_ISA_EXT_hRISCV_ISA_EXT_H
+#define RISCV_ISA_EXT_I(1UL << ('I' - 'A'))
+#define RISCV_ISA_EXT_iRISCV_ISA_EXT_I
+#define RISCV_ISA_EXT_M(1UL << ('M' - 'A'))
+#define RISCV_ISA_EXT_mRISCV_ISA_EXT_M
+#define RISCV_ISA_EXT_S(1UL << ('S' - 'A'))
+#define RISCV_ISA_EXT_sRISCV_ISA_EXT_S
+#define RISCV_ISA_EXT_U(1UL << ('U' - 'A'))
+#define RISCV_ISA_EXT_uRISCV_ISA_EXT_U
+
+extern unsigned long riscv_isa;
+
+#define riscv_isa_extension_available(ext_char)\
+   (riscv_isa & RISCV_ISA_EXT_##ext_char)
+
 #endif
 #endif
diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
index b1ade9a49347..177529d48d87 100644
--- a/arch/riscv/kernel/cpufeature.c
+++ b/arch/riscv/kernel/cpufeature.c
@@ -12,6 +12,9 @@
 #include 
 
 unsigned long elf_hwcap __read_mostly;
+unsigned long riscv_isa __read_mostly;
+EXPORT_SYMBOL_GPL(riscv_isa);
+
 #ifdef CONFIG_FPU
 bool has_fpu __read_mostly;
 #endif
@@ -20,7 +23,8 @@ void riscv_fill_hwcap(void)
 {
struct device_node *node;
const char *isa;
-   size_t i;
+   char print_str[BITS_PER_LONG+1];
+   size_t i, j, isa_len;
static unsigned long isa2hwcap[256] = {0};
 
isa2hwcap['i'] = isa2hwcap['I'] = COMPAT_HWCAP_ISA_I;
@@ -31,9 +35,11 @@ void riscv_fill_hwcap(void)
isa2hwcap['c'] = isa2hwcap['C'] = COMPAT_HWCAP_ISA_C;
 
elf_hwcap = 0;
+   riscv_isa = 0;
 
for_each_of_cpu_node(node) {
unsigned long this_hwcap = 0;
+   unsigned long this_isa = 0;
 
if (riscv_of_processor_hartid(node) < 0)
continue;
@@ -43,8 +49,22 @@ void riscv_fill_hwcap(void)
continue;
}
 
-   for (i = 0; i < strlen(isa); ++i)
+   i = 0;
+   isa_len = strlen(isa);
+#if defined(CONFIG_32BIT)
+   if (strncasecmp(isa, "rv32", 4) != 0)
+   i += 4;
+#elif defined(CONFIG_64BIT)
+   if (strncasecmp(isa, "rv64", 4) != 0)
+   i += 4;
+#endif
+   for (; i < isa_len; ++i) {
this_hwcap |= isa2hwcap[(unsigned char)(isa[i])];
+   if ('a' <= isa[i] && isa[i] <= 'z')
+   this_isa |= (1UL << (isa[i] - 'a'));
+   if ('A' <= isa[i] && isa[i] <= 'Z')
+   this_isa |= (1UL << (isa[i] - 'A'));
+   }
 
/*
 * All "okay" hart should have same isa. Set HWCAP based on
@@ -55,6 +75,11 @@ void riscv_fill_hwcap(void)
elf_hwcap &= this_hwcap;
else
elf_hwcap = this_hwcap;
+
+   if (riscv_isa)
+   riscv_isa &= this_isa;
+   else
+   riscv_isa = this_isa;
}
 
/* We don't support systems with F but without D, so mask those out
@@ -64,7 +89,17 @@ void riscv_fill_hwcap(void)
elf_hwcap &= ~COMPAT_HWCAP_ISA_F;
}
 
-   pr_info("elf_hwcap is 0x%lx\n", elf_hwcap);
+   memset(print_str, 0, sizeof(print_str));
+   for (i = 0, j = 0; i < BITS_PER_LONG; i++)
+   if (riscv_isa & (1UL 

[PATCH v2 5/5] dt-bindings: Update the isa string description

[Atish Patra]

The yaml documentation description of isa strings section doesn't
specify anything about the case sensitiveness of the isa strings.
The RISC-V specification clearly specifies it to be case insensitive.
However, Linux kernel supports only lower case isa strings.

Update the yaml documentation accordingly to avoid any confusion.

Signed-off-by: Atish Patra 
---
 Documentation/devicetree/bindings/riscv/cpus.yaml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml 
b/Documentation/devicetree/bindings/riscv/cpus.yaml
index c899111aa5e3..e22a2b7ebafa 100644
--- a/Documentation/devicetree/bindings/riscv/cpus.yaml
+++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
@@ -46,10 +46,14 @@ properties:
   - rv64imafdc
 description:
   Identifies the specific RISC-V instruction set architecture
-  supported by the hart.  These are documented in the RISC-V
+  supported by the hart. These are documented in the RISC-V
   User-Level ISA document, available from
   https://riscv.org/specifications/
 
+  Linux kernel only supports lower case isa strings. Thus,
+  isa strings must be specified in lower case in device tree
+  as well.
+
   timebase-frequency:
 type: integer
 minimum: 1
-- 
2.21.0

[PATCH v2 1/5] RISC-V: Remove per cpu clocksource

[Atish Patra]

There is only one clocksource in RISC-V. The boot cpu initializes
that clocksource. No need to keep a percpu data structure.

Signed-off-by: Atish Patra 
---
 drivers/clocksource/timer-riscv.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/clocksource/timer-riscv.c 
b/drivers/clocksource/timer-riscv.c
index 5e6038fbf115..09e031176bc6 100644
--- a/drivers/clocksource/timer-riscv.c
+++ b/drivers/clocksource/timer-riscv.c
@@ -55,7 +55,7 @@ static u64 riscv_sched_clock(void)
return get_cycles64();
 }
 
-static DEFINE_PER_CPU(struct clocksource, riscv_clocksource) = {
+static struct clocksource riscv_clocksource = {
.name   = "riscv_clocksource",
.rating = 300,
.mask   = CLOCKSOURCE_MASK(64),
@@ -92,7 +92,6 @@ void riscv_timer_interrupt(void)
 static int __init riscv_timer_init_dt(struct device_node *n)
 {
int cpuid, hartid, error;
-   struct clocksource *cs;
 
hartid = riscv_of_processor_hartid(n);
if (hartid < 0) {
@@ -112,8 +111,7 @@ static int __init riscv_timer_init_dt(struct device_node *n)
 
pr_info("%s: Registering clocksource cpuid [%d] hartid [%d]\n",
   __func__, cpuid, hartid);
-   cs = per_cpu_ptr(_clocksource, cpuid);
-   error = clocksource_register_hz(cs, riscv_timebase);
+   error = clocksource_register_hz(_clocksource, riscv_timebase);
if (error) {
pr_err("RISCV timer register failed [%d] for cpu = [%d]\n",
   error, cpuid);
-- 
2.21.0

[PATCH v2 4/5] RISC-V: Export few kernel symbols

[Atish Patra]

Export few symbols used by kvm module. Without this, kvm can not
be compiled as a module.

Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/smp.c  | 2 +-
 arch/riscv/kernel/time.c | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index 5a9834503a2f..402979f575de 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -193,4 +193,4 @@ void smp_send_reschedule(int cpu)
 {
send_ipi_message(cpumask_of(cpu), IPI_RESCHEDULE);
 }
-
+EXPORT_SYMBOL_GPL(smp_send_reschedule);
diff --git a/arch/riscv/kernel/time.c b/arch/riscv/kernel/time.c
index 541a2b885814..9dd1f2e64db1 100644
--- a/arch/riscv/kernel/time.c
+++ b/arch/riscv/kernel/time.c
@@ -9,6 +9,7 @@
 #include 
 
 unsigned long riscv_timebase;
+EXPORT_SYMBOL_GPL(riscv_timebase);
 
 void __init time_init(void)
 {
-- 
2.21.0

Re: [PATCH 1/2] KEYS: Replace uid/gid/perm permissions checking with an ACL

[Eric Biggers]

On Mon, Jul 29, 2019 at 08:49:56PM -0700, Eric Biggers wrote:
> Hi David,
> 
> On Tue, Jul 09, 2019 at 06:16:01PM -0700, Eric Biggers wrote:
> > On Thu, May 23, 2019 at 04:58:27PM +0100, David Howells wrote:
> > > Replace the uid/gid/perm permissions checking on a key with an ACL to 
> > > allow
> > > the SETATTR and SEARCH permissions to be split.  This will also allow a
> > > greater range of subjects to represented.
> > > 
> > 
> > This patch broke 'keyctl new_session', and hence broke all the fscrypt 
> > tests:
> > 
> > $ keyctl new_session
> > keyctl_session_to_parent: Permission denied
> > 
> > Output of 'keyctl show' is
> > 
> > $ keyctl show
> > Session Keyring
> >  605894913 --alswrv  0 0  keyring: _ses
> >  189223103 s-rv  0 0   \_ user: invocation_id
> > 
> > - Eric
> 
> This bug is still present in next-20190729.
> 
> - Eric

This fixes it:

diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index aa3bfcadbc660..519c94f1cc3c2 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -58,7 +58,7 @@ static struct key_acl session_keyring_acl = {
.possessor_viewable = true,
.nr_ace = 2,
.aces = {
-   KEY_POSSESSOR_ACE(KEY_ACE__PERMS & ~KEY_ACE_JOIN),
+   KEY_POSSESSOR_ACE(KEY_ACE__PERMS),
KEY_OWNER_ACE(KEY_ACE_VIEW | KEY_ACE_READ),
}
 };


The old permissions were KEY_POS_ALL | KEY_USR_VIEW | KEY_USR_READ, so
I'm not sure why JOIN permission was removed?

- Eric

Re: [PATCH 08/13] mm: remove the mask variable in hmm_vma_walk_hugetlb_entry

[Ralph Campbell]

On 7/29/19 10:51 PM, Christoph Hellwig wrote:

The pagewalk code already passes the value as the hmask parameter.

Signed-off-by: Christoph Hellwig 
---
  mm/hmm.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/mm/hmm.c b/mm/hmm.c
index f26d6abc4ed2..88b77a4a6a1e 100644
--- a/mm/hmm.c
+++ b/mm/hmm.c
@@ -771,19 +771,16 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte, 
unsigned long hmask,
  struct mm_walk *walk)
  {
  #ifdef CONFIG_HUGETLB_PAGE
-   unsigned long addr = start, i, pfn, mask;
+   unsigned long addr = start, i, pfn;
struct hmm_vma_walk *hmm_vma_walk = walk->private;
struct hmm_range *range = hmm_vma_walk->range;
struct vm_area_struct *vma = walk->vma;
-   struct hstate *h = hstate_vma(vma);
uint64_t orig_pfn, cpu_flags;
bool fault, write_fault;
spinlock_t *ptl;
pte_t entry;
int ret = 0;
  
-	mask = huge_page_size(h) - 1;

-
ptl = huge_pte_lock(hstate_vma(vma), walk->mm, pte);
entry = huge_ptep_get(pte);
  
@@ -799,7 +796,7 @@ static int hmm_vma_walk_hugetlb_entry(pte_t *pte, unsigned long hmask,

goto unlock;
}
  
-	pfn = pte_pfn(entry) + ((start & mask) >> PAGE_SHIFT);

+   pfn = pte_pfn(entry) + ((start & hmask) >> PAGE_SHIFT);


This needs to be "~hmask" so that the upper bits of the start address
are not added to the pfn. It's the middle bits of the address that
offset into the huge page that are needed.


for (; addr < end; addr += PAGE_SIZE, i++, pfn++)
range->pfns[i] = hmm_device_entry_from_pfn(range, pfn) |
 cpu_flags;

Re: [RFC 0/9] platform/x86: Huawei WMI laptop extras driver

[Ayman Bagabas]

On 19/07/25 04:05PM, Ayman Bagabas wrote:
> On 19/07/25 08:33PM, Andy Shevchenko wrote:
> > On Sun, Jun 30, 2019 at 8:41 AM Ayman Bagabas  
> > wrote:
> > >
> > > This patch series introduce changes to huawei-wmi driver that includes:
> > > * Move to platform driver
> > > * Implement WMI management interface
> > > * Add micmute LED support through WMI
> > > * Add battery charging protection support through WMI
> > > * Add fn-lock support through WMI
> > > * Implement driver quirks and parameters
> > > * Add a debugfs interface to WMI
> > >
> > > # Move to platform driver
> > >
> > > The current driver offers hotkeys and micmute led support only. With
> > > these changes, a platform driver makes more sense since it handles these
> > > changes pretty nicely.
> > >
> > > # Implement WMI management interface
> > >
> > > Huawei Matebook laptops come with two WMI interfaces. The first being
> > > WMI0 which is considered "legacy" and AFAIK only found on the Matebook X
> > > released in 2017. The second has a UID of "HWMI" and is found in pretty
> > > much all models with a slight difference in implementation except for
> > > the Matebook X (2017). Since this model has two interfaces, some aspects
> > > are controlled through the legacy interface and some through the other
> > > interface. Currently, the legacy interface is not fully implemented and
> > > is only used for hotkeys and further debugging has to be done.
> > >
> > > The WMI interface takes a 64 bit integer, although uses 32 bits most of
> > > the time, and returns a 256-260 bytes buffer consists of either one ACPI
> > > buffer of 260 bytes, in the case of Matebook X (2017), or one ACPI
> > > package of two buffers, one with 4 bytes, and the other with 256 bytes.
> > > We only care about the latter 256 buffer in both cases since the 4 bytes
> > > always return zeros. The first byte of this 256 buffer always has the
> > > return status where 1 indicated error. Some models require calling the
> > > WMI interface twice to execute a command.
> > >
> > > # Add micmute LED support through WMI
> > >
> > > After implementing the WMI interface, micmute LED can be controlled
> > > easily. Models with the legacy interface fall back to ACPI EC method
> > > control since the legacy interface is not implemented.
> > >
> > > # Add battery charging protection support through WMI
> > >
> > > Most models, that has the WMI interface, are capable of battery
> > > protection where it can control battery charging thresholds and limits
> > > charging the battery to certain values.
> > >
> > > # Add fn-lock support through WMI
> > >
> > > The behavior of hotkeys is not the same among all models. Some models
> > > require fn-lock to do things like `Ctrl-Ins` or `Alt-PrtSc`. By default,
> > > hotkeys behave as special keys (media keys, Ins, etc), but if a modifier
> > > is used (ctrl, alt, shift) these keys behave as F1-F12 keys. If the Fn
> > > key is toggled on, the hotkeys with or without a modifier, behave as
> > > F1-F12 keys. This makes it impossible to use a modifier and `PrtSc` or
> > > `Ins`.
> > >
> > > Now, some models fix this by excluding `PrtSc` and `Ins` keys from being
> > > treated as F11 and F12 keys with the use of a modifier. However, some
> > > models do not, and fixes this by the so called fn-lock.
> > >
> > > Fn-lock inverts the behavior of the top row from special keys to F1-F12
> > > keys. So a modifier and a special key would be possible which make
> > > things like `Alt-Ins` possible. Now, with fn-lock we would have 4 modes:
> > >
> > > * Fn-key off & fn-lock off - hotkeys treated as special keys using a
> > >   modifier gives F1-F12 keys.
> > > * Fn-key on & fn-lock off - hotkeys treated as F1-F12 keys and using a
> > >   modifier gives F1-F12.
> > > * Fn-key off & fn-lock on - hotkeys are treated as F1-F12 keys and using
> > >   a modifier gives special keys.
> > > * Fn-key on & fn-lock on - hotkeys are treated as special keys and using
> > >   a modifier gives special keys.
> > >
> > > # Implement driver quirks and parameters
> > >
> > > The driver introduces 3 quirks and 2 parameters that can change the
> > > driver's behavior. These quirks being as:
> > > 1. Fixes reporting brightness keys twice since it's already handled by
> > >acpi-video.
> > > 2. Some models need a short delay when setting battery thresholds to
> > >prevent a race condition when two processes read/write.
> > > 3. Matebook X (2017) handles micmute led through the "legacy" interface
> > >which is not currently implemented. Use ACPI EC method to control
> > >this led.
> > >
> > > and the 2 parameters can enforce the behavior of quirk 1 & 2.
> > >
> > > # Add a debugfs interface to WMI
> > >
> > > An interface to the WMI management interface that allows easier
> > > debugging.
> > >
> > 
> > It doesn't apply to current for-next.
> 
> Hey Andi,
I'm sorry, I meant Andy.
> 
> I was basing them on the stable branch.
> 
> It doesn't apply because of commit 

Re: [PATCH] ARM: dts: aspeed: Add Mihawk BMC platform

[Andrew Jeffery]

Hello Ben,

Thanks for the patch! Some minor comments below.

On Tue, 30 Jul 2019, at 15:30, Ben Pai wrote:
> The Mihawk BMC is an ASPEED ast2500 based BMC that is part of an
> OpenPower Power9 server.
> 
> This adds the device tree description for most upstream components. It
> is a squashed commit from the OpenBMC kernel tree.

That it's a squashed commit isn't relevant, neither is the mention of the 
OpenBMC
kernel tree. I'd drop both from the commit message.

> 
> Signed-off-by: Ben Pai 
> ---
>  arch/arm/boot/dts/Makefile  |   1 +
>  arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 922 
>  2 files changed, 923 insertions(+)
>  create mode 100755 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index eb6de52c1936..262345544359 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -1281,5 +1281,6 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
>   aspeed-bmc-opp-vesnin.dtb \
>   aspeed-bmc-opp-witherspoon.dtb \
>   aspeed-bmc-opp-zaius.dtb \
> + aspeed-bmc-opp-mihawk.dtb \
>   aspeed-bmc-portwell-neptune.dtb \
>   aspeed-bmc-quanta-q71l.dtb
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts 
> b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> new file mode 100755
> index ..cfa20e0b2939
> --- /dev/null
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
> @@ -0,0 +1,922 @@
> +/dts-v1/;
> +
> +#include "aspeed-g5.dtsi"
> +#include 
> +#include 
> +
> +/ {
> + model = "Mihawk BMC";
> + compatible = "ibm,mihawk-bmc", "aspeed,ast2500";

I think this should be "ips,mihawk-bmc". You may also need to add "ips" to the
vendor-prefixes list. 

> +
> +
> + chosen {
> + stdout-path = 
> + bootargs = "console=ttyS4,115200 earlyprintk";
> + };
> +
> + memory@8000 {
> + reg = <0x8000 0x2000>; /* address and size of 
> RAM(512MB) */
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + flash_memory: region@9800 {
> + no-map;
> + reg = <0x9800 0x0400>; /* 64M */
> + };
> +
> + gfx_memory: framebuffer {
> + size = <0x0100>;
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> +
> + video_engine_memory: jpegbuffer {
> + size = <0x0200>;/* 32MM */
> + alignment = <0x0100>;
> + compatible = "shared-dma-pool";
> + reusable;
> + };
> + };
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> +
> + air-water {
> + label = "air-water";
> + gpios = < ASPEED_GPIO(F, 6) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + checkstop {
> + label = "checkstop";
> + gpios = < ASPEED_GPIO(J, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps0-presence {
> + label = "ps0-presence";
> + gpios = < ASPEED_GPIO(Z, 2) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> +
> + ps1-presence {
> + label = "ps1-presence";
> + gpios = < ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + id-button {
> + label = "id-button";
> + gpios = < ASPEED_GPIO(F, 1) GPIO_ACTIVE_LOW>;
> + linux,code = ;
> + };
> + };
> +
> + gpio-keys-polled {
> + compatible = "gpio-keys-polled";
> + #address-cells = <1>;
> + #size-cells = <0>;

Please remove the #address-cells and #size-cells properties, they aren't
relevant for gpio-keys-polled.

> + poll-interval = <1000>;
> +
> + fan0-presence {
> + label = "fan0-presence";
> + gpios = < 9 GPIO_ACTIVE_LOW>;
> + linux,code = <9>;
> + };
> +
> + fan1-presence {
> + label = "fan1-presence";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + linux,code = <10>;
> + };
> +
> + fan2-presence {
> + label = "fan2-presence";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + linux,code = <11>;
> + };
> +
> + fan3-presence {
> + label = "fan3-presence";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + 

Re: [PATCH 12/20] fs: fat: Initialize filesystem timestamp ranges

[OGAWA Hirofumi]

Deepa Dinamani  writes:

>> At least, it is wrong to call fat_time_fat2unix() before setup parameters
>> in sbi.
>
> All the parameters that fat_time_fat2unix() cares in sbi is accessed through
>
> static inline int fat_tz_offset(struct msdos_sb_info *sbi)
> {
> return (sbi->options.tz_set ?
>-sbi->options.time_offset :
>sys_tz.tz_minuteswest) * SECS_PER_MIN;
> }
>
> Both the sbi fields sbi->options.tz_set and sbi->options.time_offset
> are set by the call to parse_options(). And, parse_options() is called
> before the calls to fat_time_fat2unix().:
>
> int fat_fill_super(struct super_block *sb, void *data, int silent, int isvfat,
>void (*setup)(struct super_block *))
> {
>  
>
> error = parse_options(sb, data, isvfat, silent, , >options);
> if (error)
> goto out_fail;
>
>
>
> sbi->prev_free = FAT_START_ENT;
> sb->s_maxbytes = 0x;
> fat_time_fat2unix(sbi, , 0, cpu_to_le16(FAT_DATE_MIN), 0);
> sb->s_time_min = ts.tv_sec;
>
> fat_time_fat2unix(sbi, , cpu_to_le16(FAT_TIME_MAX),
>   cpu_to_le16(FAT_DATE_MAX), 0);
> sb->s_time_max = ts.tv_sec;
>
>
> }
>
> I do not see what the problem is.

Ouch, you are right. I was reading that patch wrongly, sorry.

Thanks.
-- 
OGAWA Hirofumi 

linux-next: manual merge of the fsverity tree with the f2fs tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the fsverity tree got conflicts in:

  fs/f2fs/file.c
  fs/f2fs/inode.c

between commits:

  cf3dbe1481d1 ("f2fs: support FS_IOC_{GET,SET}FSLABEL")
  01ff2b3740a6 ("f2fs: Support case-insensitive file name lookups")

from the f2fs tree and commit:

  60d7bf0f790f ("f2fs: add fs-verity support")

from the fsverity tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/f2fs/file.c
index eb1aa9b75eda,838bfeecbd86..
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@@ -1721,7 -1721,7 +1729,8 @@@ static const struct 
FS_ENCRYPT_FL | \
FS_INLINE_DATA_FL | \
FS_NOCOW_FL |   \
-   FS_CASEFOLD_FL)
++  FS_CASEFOLD_FL |\
+   FS_VERITY_FL)
  
  #define F2FS_SETTABLE_FS_FL ( \
FS_SYNC_FL |\
@@@ -3080,86 -3088,34 +3091,110 @@@ static int f2fs_ioc_resize_fs(struct fi
return ret;
  }
  
 +static int f2fs_get_volume_name(struct file *filp, unsigned long arg)
 +{
 +  struct inode *inode = file_inode(filp);
 +  struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
 +  char *vbuf;
 +  int count;
 +  int err = 0;
 +
 +  vbuf = f2fs_kzalloc(sbi, MAX_VOLUME_NAME, GFP_KERNEL);
 +  if (!vbuf)
 +  return -ENOMEM;
 +
 +  down_read(>sb_lock);
 +  count = utf16s_to_utf8s(sbi->raw_super->volume_name,
 +  sizeof(sbi->raw_super->volume_name),
 +  UTF16_LITTLE_ENDIAN, vbuf, MAX_VOLUME_NAME);
 +  up_read(>sb_lock);
 +
 +  if (copy_to_user((char __user *)arg, vbuf,
 +  min(FSLABEL_MAX, count)))
 +  err = -EFAULT;
 +
 +  kvfree(vbuf);
 +  return err;
 +}
 +
 +static int f2fs_set_volume_name(struct file *filp, unsigned long arg)
 +{
 +  struct inode *inode = file_inode(filp);
 +  struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
 +  char *vbuf;
 +  int len;
 +  int err = 0;
 +
 +  vbuf = f2fs_kzalloc(sbi, MAX_VOLUME_NAME, GFP_KERNEL);
 +  if (!vbuf)
 +  return -ENOMEM;
 +
 +  if (copy_from_user(vbuf, (char __user *)arg, FSLABEL_MAX)) {
 +  err = -EFAULT;
 +  goto out;
 +  }
 +
 +  len = strnlen(vbuf, FSLABEL_MAX);
 +  if (len > FSLABEL_MAX - 1) {
 +  err = -EINVAL;
 +  goto out;
 +  }
 +
 +  err = mnt_want_write_file(filp);
 +  if (err)
 +  goto out;
 +
 +  down_write(>sb_lock);
 +
 +  memset(sbi->raw_super->volume_name, 0,
 +  sizeof(sbi->raw_super->volume_name));
 +  utf8s_to_utf16s(vbuf, MAX_VOLUME_NAME, UTF16_LITTLE_ENDIAN,
 +  sbi->raw_super->volume_name,
 +  sizeof(sbi->raw_super->volume_name));
 +
 +  err = f2fs_commit_super(sbi, false);
 +
 +  up_write(>sb_lock);
 +
 +  mnt_drop_write_file(filp);
 +out:
 +  kvfree(vbuf);
 +  return err;
 +}
 +
+ static int f2fs_ioc_enable_verity(struct file *filp, unsigned long arg)
+ {
+   struct inode *inode = file_inode(filp);
+ 
+   f2fs_update_time(F2FS_I_SB(inode), REQ_TIME);
+ 
+   if (!f2fs_sb_has_verity(F2FS_I_SB(inode))) {
+   f2fs_warn(F2FS_I_SB(inode),
+ "Can't enable fs-verity on inode %lu: the verity 
feature is not enabled on this filesystem.\n",
+ inode->i_ino);
+   return -EOPNOTSUPP;
+   }
+ 
+   return fsverity_ioctl_enable(filp, (const void __user *)arg);
+ }
+ 
+ static int f2fs_ioc_measure_verity(struct file *filp, unsigned long arg)
+ {
+   if (!f2fs_sb_has_verity(F2FS_I_SB(file_inode(filp
+   return -EOPNOTSUPP;
+ 
+   return fsverity_ioctl_measure(filp, (void __user *)arg);
+ }
+ 
  long f2fs_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
  {
 +  int ret;
 +
if (unlikely(f2fs_cp_error(F2FS_I_SB(file_inode(filp)
return -EIO;
 +  ret = f2fs_is_checkpoint_ready(F2FS_I_SB(file_inode(filp)));
 +  if (ret)
 +  return ret;
  
switch (cmd) {
case F2FS_IOC_GETFLAGS:
@@@ -3214,10 -3170,10 +3249,14 @@@
return f2fs_ioc_precache_extents(filp, arg);
case F2FS_IOC_RESIZE_FS:
return f2fs_ioc_resize_fs(filp, arg);
 +  case F2FS_IOC_GET_VOLUME_NAME:
 +  return f2fs_get_volume_name(filp, arg);
 +  case F2FS_IOC_SET_VOLUME_NAME:
 +  return f2fs_set_volume_name(filp, arg);
+   case FS_IOC_ENABLE_VERITY:
+   return 

[PATCH v2] Fix annotate.c use of uninitialized value error

[Numfor Mbiziwo-Tiapo]

Our local MSAN (Memory Sanitizer) build of perf throws a warning
that comes from the "dso__disassemble_filename" function in
"tools/perf/util/annotate.c" when running perf record.

The warning stems from the call to readlink, in which "build_id_path"
was being read into "linkname". Since readlink does not null terminate,
an uninitialized memory access would later occur when "linkname" is
passed into the strstr function. This is simply fixed by null-terminating
"linkname" after the call to readlink.

To reproduce this warning, build perf by running:
make -C tools/perf CLANG=1 CC=clang EXTRA_CFLAGS="-fsanitize=memory\
 -fsanitize-memory-track-origins"

(Additionally, llvm might have to be installed and clang might have to
be specified as the compiler - export CC=/usr/bin/clang)

then running:
tools/perf/perf record -o - ls / | tools/perf/perf --no-pager annotate\
 -i - --stdio

Please see the cover letter for why false positive warnings may be
generated.

Signed-off-by: Numfor Mbiziwo-Tiapo 
---
 tools/perf/util/annotate.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 70de8f6b3aee..e1b075b52dce 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1627,6 +1627,7 @@ static int dso__disassemble_filename(struct dso *dso, 
char *filename, size_t fil
char *build_id_filename;
char *build_id_path = NULL;
char *pos;
+   int len;
 
if (dso->symtab_type == DSO_BINARY_TYPE__KALLSYMS &&
!dso__is_kcore(dso))
@@ -1655,10 +1656,16 @@ static int dso__disassemble_filename(struct dso *dso, 
char *filename, size_t fil
if (pos && strlen(pos) < SBUILD_ID_SIZE - 2)
dirname(build_id_path);
 
-   if (dso__is_kcore(dso) ||
-   readlink(build_id_path, linkname, sizeof(linkname)) < 0 ||
-   strstr(linkname, DSO__NAME_KALLSYMS) ||
-   access(filename, R_OK)) {
+   if (dso__is_kcore(dso))
+   goto fallback;
+
+   len = readlink(build_id_path, linkname, sizeof(linkname) - 1);
+   if (len < 0)
+   goto fallback;
+
+   linkname[len] = '\0';
+   if (strstr(linkname, DSO__NAME_KALLSYMS) ||
+   access(filename, R_OK)) {
 fallback:
/*
 * If we don't have build-ids or the build-id file isn't in the
-- 
2.22.0.709.g102302147b-goog