Re: [PATCH 4/8] perf daemon: Add daemon command

2020-12-15 Thread Alexei Budankov


On 15.12.2020 22:43, Jiri Olsa wrote:
> On Tue, Dec 15, 2020 at 06:40:26PM +0300, Alexei Budankov wrote:
>> Hi,
>>
>> On 12.12.2020 13:43, Jiri Olsa wrote:
>>> Adding daemon command that allows to run record sessions
>>> on background. Each session represents one perf record
>>> process and is configured in config file.
>>>
>>> Example:
>>>
>>>   # cat config.daemon
>>>   [daemon]
>>>   base=/opt/perfdata
>>
>> It could probably make sense to consider using locations at /var/
>> directory, similar to other already existing daemon processes in
>> system so admin and user experience would be easily reusabe for
>> performance monitoring daemon (service).
> 
> hm, you can specify any /var path in there if you like,
> do you suggest to hardcode it?

This thing: https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard
Since Perf is a part of OS it would better use some standardized locations.

> 
>>
>>>
>>>   [session-1]
>>>   run = -m 10M -e cycles -o /opt/perfdata/1/perf.data --overwrite 
>>> --switch-output -a
>>>
>>>   [session-2]
>>>   run = -m 20M -e sched:* -o /opt/perfdata/2/perf.data --overwrite 
>>> --switch-output -a
>>>
>>> Default perf config has the same daemon base:
>>>
>>>   # cat ~/.perfconfig
>>>   [daemon]
>>>   base=/opt/perfdata
>>>
>>> Starting the daemon:
>>>
>>>   # perf daemon --config config.daemon
>>
>> It could make sense to name daemon config file similar to .perfconfig
>> e.g. like .perfconfig.daemon. perf daemon command would then assume, by
>> default, usage of .perfconfig.daemon config or the one specified on the
>> command line via --config option. It also would be helpfull have loaded
>> config file path printed into console:
>> # perf daemon
>> Daemon process  started with config /path/to/.perfconfig.daemon
> 
> so the current way is, that following creates daemon:
> 
>   # perf daemon --config 
> 
> and any other 'non --config' option' is used to 'query/control' daemon:
> 
>   # perf daemon
>   # perf daemon --signal
>   # perf daemon --stop
>   ...
> 
> 
> I'd like to keep short way checking on daemon, without too many
> options, like:
> 
>   # perf daemon
>   [690174:daemon] base: /opt/perfdata
>   [690175:top] perf record -e cycles --switch-output=1m --switch-max-files=6 
> -a
> 
> 
> I think maybe we don't need any other .perfconfig, we could have
> all in standard .perfconfig, like:
> 
>   # cat .perfconfig:
>   [daemon]
>   base=/opt/perfdata
> 
>   [session-1]
>   run = -m 1M -e cycles --overwrite --switch-output -a
>   [session-2]
>   run = -m 1M -e sched:* --overwrite --switch-output -a
> 
> 
> and to run daemon on top of it:
> 
>   # perf daemon --start
> 
> 
> to run daemon with alternate config:
> 
>   # perf daemon --start=
> 
> or:
> 
>   # perf daemon --start --config=
> 
> 
> and checking on daemon with default .perfconfig setup:
> 
>   # perf daemon
> 
> 
> checking on daemon with different base or config:
> 
>   # perf daemon --base=
>   # perf daemon --config=
>   # perf daemon --base= --stop
>   # perf daemon --base= --signal
>   # perf daemon --config= --stop
>   # perf daemon --config= --signal
> 
> how about that?

Extending .perfconfig would look simpler for users, IHMO.
It looks like --base option actually implements --sandbox
or similar semantics.

> 
> SNIP
> 
>>> +static struct session*
>>> +daemon__find_session(struct daemon *daemon, char *name)
>>> +{
>>> +   struct session *session;
>>> +
>>> +   list_for_each_entry(session, >sessions, list) {
>>> +   if (!strcmp(session->name, name))
>>> +   return session;
>>> +   }
>>> +
>>> +   return NULL;
>>> +}
>>> +
>>> +static int session_name(const char *var, char *session, int len)
>>
>> should possibly name it get_session_name.
> 
> ok
> 
>>
>>> +{
>>> +   const char *p = var + sizeof("session-") - 1;
>>
>> should possibly check that p still points inside [var, var+len).
> 
> ok
> 
> SNIP
> 
>>> +static int session__wait(struct session *session, struct daemon *daemon,
>>> +int secs)
>>> +{
>>> +   time_t current, start = 0;
>>> +   int cnt;
>>> +
>>> +   start = current = time(NULL);
>>> +
>>> +   do {
>>> +   usleep(500);
>>
>> This polling design is actually sub-optimal because it induces redundant
>> noise in a system. Ideally it should be implemented in async fashion so
>> kernel would atomically notify daemon process on event happened in some
>> of record processes e.g. using of poll-like() system call.
> 
> ok, any suggestion?

Possibly, checking SIGCHLDs via signalfd [1] OR using pidfd [2] on kernel v5.3+

[1] https://man7.org/linux/man-pages/man2/signalfd.2.html
[2] https://man7.org/linux/man-pages/man2/pidfd_open.2.html

Thanks,
Alexei

> 
>>
>>> +   cnt = session__check(session, daemon);
>>> +   if (cnt)
>>> +   break;
>>> +
>>> +   current = time(NULL);
>>> +   } while ((start + secs > current));
>>> +
>>> +   return cnt;
>>> +}
>>> +
>>> +static int session__signal(struct session *session, 

[GIT PULL] Backlight for v5.11

2020-12-15 Thread Lee Jones
Good morning Linus,

Careful, it's a big one!

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/backlight.git 
backlight-next-5.11

for you to fetch changes up to 789eb04b6c569e3e5007afd040bef5d7216d2f3a:

  backlight: pwm_bl: Fix interpolation (2020-11-04 15:54:57 +)


 - Bug Fixes
   - Fix interpolation issues by switching to a linear algorithm; pwm_bl


Alexandru Stan (1):
  backlight: pwm_bl: Fix interpolation

 drivers/video/backlight/pwm_bl.c | 70 ++--
 1 file changed, 31 insertions(+), 39 deletions(-)

-- 
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


[PATCH v4 7/9] regulator: mt6359: Set the enable time for LDOs

2020-12-15 Thread Hsin-Hsiung Wang
Add the enable time for LDOs.
This patch is preparing for adding mt6359p regulator support.

Signed-off-by: Hsin-Hsiung Wang 
Acked-by: Mark Brown 
---
 drivers/regulator/mt6359-regulator.c | 65 ++--
 1 file changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/regulator/mt6359-regulator.c 
b/drivers/regulator/mt6359-regulator.c
index 4ac6380f9875..e46fb95b87e2 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -103,7 +103,7 @@ struct mt6359_regulator_info {
 
 #define MT6359_LDO(match, _name, _volt_table,  \
_enable_reg, _enable_mask, _status_reg, \
-   _vsel_reg, _vsel_mask)  \
+   _vsel_reg, _vsel_mask, _en_delay)   \
 [MT6359_ID_##_name] = {\
.desc = {   \
.name = #_name, \
@@ -118,6 +118,7 @@ struct mt6359_regulator_info {
.vsel_mask = _vsel_mask,\
.enable_reg = _enable_reg,  \
.enable_mask = BIT(_enable_mask),   \
+   .enable_time = _en_delay,   \
},  \
.status_reg = _status_reg,  \
.qi = BIT(0),   \
@@ -466,15 +467,18 @@ static struct mt6359_regulator_info mt6359_regulators[] = 
{
MT6359_LDO("ldo_vsim1", VSIM1, vsim1_voltages,
   MT6359_RG_LDO_VSIM1_EN_ADDR, MT6359_RG_LDO_VSIM1_EN_SHIFT,
   MT6359_DA_VSIM1_B_EN_ADDR, MT6359_RG_VSIM1_VOSEL_ADDR,
-  MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT),
+  MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT,
+  480),
MT6359_LDO("ldo_vibr", VIBR, vibr_voltages,
   MT6359_RG_LDO_VIBR_EN_ADDR, MT6359_RG_LDO_VIBR_EN_SHIFT,
   MT6359_DA_VIBR_B_EN_ADDR, MT6359_RG_VIBR_VOSEL_ADDR,
-  MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT),
+  MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT,
+  240),
MT6359_LDO("ldo_vrf12", VRF12, vrf12_voltages,
   MT6359_RG_LDO_VRF12_EN_ADDR, MT6359_RG_LDO_VRF12_EN_SHIFT,
   MT6359_DA_VRF12_B_EN_ADDR, MT6359_RG_VRF12_VOSEL_ADDR,
-  MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT),
+  MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT,
+  120),
MT6359_REG_FIXED("ldo_vusb", VUSB, MT6359_RG_LDO_VUSB_EN_0_ADDR,
 MT6359_DA_VUSB_B_EN_ADDR, 300),
MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, 50, 1293750, 6250,
@@ -486,11 +490,13 @@ static struct mt6359_regulator_info mt6359_regulators[] = 
{
MT6359_LDO("ldo_vio18", VIO18, volt18_voltages,
   MT6359_RG_LDO_VIO18_EN_ADDR, MT6359_RG_LDO_VIO18_EN_SHIFT,
   MT6359_DA_VIO18_B_EN_ADDR, MT6359_RG_VIO18_VOSEL_ADDR,
-  MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT),
+  MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT,
+  960),
MT6359_LDO("ldo_vcamio", VCAMIO, volt18_voltages,
   MT6359_RG_LDO_VCAMIO_EN_ADDR, MT6359_RG_LDO_VCAMIO_EN_SHIFT,
   MT6359_DA_VCAMIO_B_EN_ADDR, MT6359_RG_VCAMIO_VOSEL_ADDR,
-  MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT),
+  MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT,
+  1290),
MT6359_REG_FIXED("ldo_vcn18", VCN18, MT6359_RG_LDO_VCN18_EN_ADDR,
 MT6359_DA_VCN18_B_EN_ADDR, 180),
MT6359_REG_FIXED("ldo_vfe28", VFE28, MT6359_RG_LDO_VFE28_EN_ADDR,
@@ -498,19 +504,20 @@ static struct mt6359_regulator_info mt6359_regulators[] = 
{
MT6359_LDO("ldo_vcn13", VCN13, vcn13_voltages,
   MT6359_RG_LDO_VCN13_EN_ADDR, MT6359_RG_LDO_VCN13_EN_SHIFT,
   MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
-  MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT),
+  MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
+  240),
MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, vcn33_voltages,
   MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
   MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
   MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
   MT6359_RG_VCN33_1_VOSEL_MASK <<
-  MT6359_RG_VCN33_1_VOSEL_SHIFT),
+  MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, 

[PATCH v4 6/9] regulator: mt6359: Add support for MT6359 regulator

2020-12-15 Thread Hsin-Hsiung Wang
From: Wen Su 

The MT6359 is a regulator found on boards based on MediaTek MT6779 and
probably other SoCs. It is a so called pmic and connects as a slave to
SoC using SPI, wrapped inside the pmic-wrapper.

Signed-off-by: Wen Su 
Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/regulator/Kconfig  |   9 +
 drivers/regulator/Makefile |   1 +
 drivers/regulator/mt6359-regulator.c   | 649 +
 include/linux/regulator/mt6359-regulator.h |  58 ++
 4 files changed, 717 insertions(+)
 create mode 100644 drivers/regulator/mt6359-regulator.c
 create mode 100644 include/linux/regulator/mt6359-regulator.h

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 020a00d6696b..7572efc38bd5 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -721,6 +721,15 @@ config REGULATOR_MT6358
  This driver supports the control of different power rails of device
  through regulator interface.
 
+config REGULATOR_MT6359
+   tristate "MediaTek MT6359 PMIC"
+   depends on MFD_MT6397
+   help
+ Say y here to select this option to enable the power regulator of
+ MediaTek MT6359 PMIC.
+ This driver supports the control of different power rails of device
+ through regulator interface.
+
 config REGULATOR_MT6360
tristate "MT6360 SubPMIC Regulator"
depends on MFD_MT6360
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 6ebae516258e..56c28ab191e4 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -89,6 +89,7 @@ obj-$(CONFIG_REGULATOR_MPQ7920) += mpq7920.o
 obj-$(CONFIG_REGULATOR_MT6311) += mt6311-regulator.o
 obj-$(CONFIG_REGULATOR_MT6323) += mt6323-regulator.o
 obj-$(CONFIG_REGULATOR_MT6358) += mt6358-regulator.o
+obj-$(CONFIG_REGULATOR_MT6359) += mt6359-regulator.o
 obj-$(CONFIG_REGULATOR_MT6360) += mt6360-regulator.o
 obj-$(CONFIG_REGULATOR_MT6380) += mt6380-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
diff --git a/drivers/regulator/mt6359-regulator.c 
b/drivers/regulator/mt6359-regulator.c
new file mode 100644
index ..4ac6380f9875
--- /dev/null
+++ b/drivers/regulator/mt6359-regulator.c
@@ -0,0 +1,649 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (c) 2020 MediaTek Inc.
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MT6359_BUCK_MODE_AUTO  0
+#define MT6359_BUCK_MODE_FORCE_PWM 1
+#define MT6359_BUCK_MODE_NORMAL0
+#define MT6359_BUCK_MODE_LP2
+
+/*
+ * MT6359 regulators' information
+ *
+ * @desc: standard fields of regulator description.
+ * @status_reg: for query status of regulators.
+ * @qi: Mask for query enable signal status of regulators.
+ * @modeset_reg: for operating AUTO/PWM mode register.
+ * @modeset_mask: MASK for operating modeset register.
+ * @modeset_shift: SHIFT for operating modeset register.
+ */
+struct mt6359_regulator_info {
+   struct regulator_desc desc;
+   u32 status_reg;
+   u32 qi;
+   u32 modeset_reg;
+   u32 modeset_mask;
+   u32 modeset_shift;
+   u32 lp_mode_reg;
+   u32 lp_mode_mask;
+   u32 lp_mode_shift;
+};
+
+#define MT6359_BUCK(match, _name, min, max, step, min_sel, \
+   volt_ranges, _enable_reg, _status_reg,  \
+   _vsel_reg, _vsel_mask,  \
+   _lp_mode_reg, _lp_mode_shift,   \
+   _modeset_reg, _modeset_shift)   \
+[MT6359_ID_##_name] = {\
+   .desc = {   \
+   .name = #_name, \
+   .of_match = of_match_ptr(match),\
+   .ops = _volt_range_ops,  \
+   .type = REGULATOR_VOLTAGE,  \
+   .id = MT6359_ID_##_name,\
+   .owner = THIS_MODULE,   \
+   .uV_step = (step),  \
+   .linear_min_sel = (min_sel),\
+   .n_voltages = ((max) - (min)) / (step) + 1, \
+   .min_uV = (min),\
+   .linear_ranges = volt_ranges,   \
+   .n_linear_ranges = ARRAY_SIZE(volt_ranges), \
+   .vsel_reg = _vsel_reg,  \
+   .vsel_mask = _vsel_mask,\
+   .enable_reg = _enable_reg,  \
+   .enable_mask = BIT(0),  \
+   .of_map_mode = mt6359_map_mode, \
+   },  \
+   .status_reg = _status_reg,  \
+ 

[PATCH v4 9/9] arm64: dts: mt6359: add PMIC MT6359 related nodes

2020-12-15 Thread Hsin-Hsiung Wang
From: Wen Su 

add PMIC MT6359 related nodes which is for MT6779 platform

Signed-off-by: Wen Su 
Signed-off-by: Hsin-Hsiung Wang 
---
 arch/arm64/boot/dts/mediatek/mt6359.dtsi | 298 +++
 1 file changed, 298 insertions(+)
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6359.dtsi

diff --git a/arch/arm64/boot/dts/mediatek/mt6359.dtsi 
b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
new file mode 100644
index ..649c661e9907
--- /dev/null
+++ b/arch/arm64/boot/dts/mediatek/mt6359.dtsi
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+ {
+   pmic: pmic {
+   compatible = "mediatek,mt6359";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+
+   mt6359codec: mt6359codec {
+   };
+
+   mt6359regulator: mt6359regulator {
+   mt6359_vs1_buck_reg: buck_vs1 {
+   regulator-name = "vs1";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <220>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-always-on;
+   };
+   mt6359_vgpu11_buck_reg: buck_vgpu11 {
+   regulator-name = "vgpu11";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1193750>;
+   regulator-ramp-delay = <5000>;
+   regulator-enable-ramp-delay = <200>;
+   regulator-allowed-modes = <0 1 2>;
+   };
+   mt6359_vmodem_buck_reg: buck_vmodem {
+   regulator-name = "vmodem";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <110>;
+   regulator-ramp-delay = <10760>;
+   regulator-enable-ramp-delay = <200>;
+   };
+   mt6359_vpu_buck_reg: buck_vpu {
+   regulator-name = "vpu";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1193750>;
+   regulator-ramp-delay = <5000>;
+   regulator-enable-ramp-delay = <200>;
+   regulator-allowed-modes = <0 1 2>;
+   };
+   mt6359_vcore_buck_reg: buck_vcore {
+   regulator-name = "vcore";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <130>;
+   regulator-ramp-delay = <5000>;
+   regulator-enable-ramp-delay = <200>;
+   regulator-allowed-modes = <0 1 2>;
+   };
+   mt6359_vs2_buck_reg: buck_vs2 {
+   regulator-name = "vs2";
+   regulator-min-microvolt = <80>;
+   regulator-max-microvolt = <160>;
+   regulator-enable-ramp-delay = <0>;
+   regulator-always-on;
+   };
+   mt6359_vpa_buck_reg: buck_vpa {
+   regulator-name = "vpa";
+   regulator-min-microvolt = <50>;
+   regulator-max-microvolt = <365>;
+   regulator-enable-ramp-delay = <300>;
+   };
+   mt6359_vproc2_buck_reg: buck_vproc2 {
+   regulator-name = "vproc2";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1193750>;
+   regulator-ramp-delay = <7500>;
+   regulator-enable-ramp-delay = <200>;
+   regulator-allowed-modes = <0 1 2>;
+   };
+   mt6359_vproc1_buck_reg: buck_vproc1 {
+   regulator-name = "vproc1";
+   regulator-min-microvolt = <40>;
+   regulator-max-microvolt = <1193750>;
+   regulator-ramp-delay = <7500>;
+   regulator-enable-ramp-delay = <200>;
+   regulator-allowed-modes = <0 1 2>;
+   };
+   mt6359_vcore_sshub_buck_reg: buck_vcore_sshub {
+   regulator-name = "vcore_sshub";
+   

[PATCH v4 5/9] mfd: Add support for the MediaTek MT6359 PMIC

2020-12-15 Thread Hsin-Hsiung Wang
This adds support for the MediaTek MT6359 PMIC. This is a
multifunction device with the following sub modules:

- Codec
- Interrupt
- Regulator
- RTC

It is interfaced to the host controller using SPI interface
by a proprietary hardware called PMIC wrapper or pwrap.
MT6359 MFD is a child device of the pwrap.

Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/mfd/mt6358-irq.c |  24 ++
 drivers/mfd/mt6397-core.c|  28 ++
 include/linux/mfd/mt6359/core.h  | 133 +++
 include/linux/mfd/mt6359/registers.h | 529 +++
 include/linux/mfd/mt6397/core.h  |   1 +
 5 files changed, 715 insertions(+)
 create mode 100644 include/linux/mfd/mt6359/core.h
 create mode 100644 include/linux/mfd/mt6359/registers.h

diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
index 4b094e5e51cc..83f3ffbdbb4c 100644
--- a/drivers/mfd/mt6358-irq.c
+++ b/drivers/mfd/mt6358-irq.c
@@ -5,6 +5,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -26,6 +28,17 @@ static const struct irq_top_t mt6358_ints[] = {
MT6358_TOP_GEN(MISC),
 };
 
+static const struct irq_top_t mt6359_ints[] = {
+   MT6359_TOP_GEN(BUCK),
+   MT6359_TOP_GEN(LDO),
+   MT6359_TOP_GEN(PSC),
+   MT6359_TOP_GEN(SCK),
+   MT6359_TOP_GEN(BM),
+   MT6359_TOP_GEN(HK),
+   MT6359_TOP_GEN(AUD),
+   MT6359_TOP_GEN(MISC),
+};
+
 static struct pmic_irq_data mt6358_irqd = {
.num_top = ARRAY_SIZE(mt6358_ints),
.num_pmic_irqs = MT6358_IRQ_NR,
@@ -33,6 +46,13 @@ static struct pmic_irq_data mt6358_irqd = {
.pmic_ints = mt6358_ints,
 };
 
+static struct pmic_irq_data mt6359_irqd = {
+   .num_top = ARRAY_SIZE(mt6359_ints),
+   .num_pmic_irqs = MT6359_IRQ_NR,
+   .top_int_status_reg = MT6359_TOP_INT_STATUS0,
+   .pmic_ints = mt6359_ints,
+};
+
 static void pmic_irq_enable(struct irq_data *data)
 {
unsigned int hwirq = irqd_to_hwirq(data);
@@ -195,6 +215,10 @@ int mt6358_irq_init(struct mt6397_chip *chip)
chip->irq_data = _irqd;
break;
 
+   case MT6359_CHIP_ID:
+   chip->irq_data = _irqd;
+   break;
+
default:
dev_err(chip->dev, "unsupported chip: 0x%x\n", chip->chip_id);
return -ENODEV;
diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
index f6cd8a660602..07240eaf4055 100644
--- a/drivers/mfd/mt6397-core.c
+++ b/drivers/mfd/mt6397-core.c
@@ -13,9 +13,11 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define MT6323_RTC_BASE0x8000
@@ -99,6 +101,21 @@ static const struct mfd_cell mt6358_devs[] = {
},
 };
 
+static const struct mfd_cell mt6359_devs[] = {
+   {
+   .name = "mt6359-regulator",
+   .of_compatible = "mediatek,mt6359-regulator",
+   }, {
+   .name = "mt6359-rtc",
+   .num_resources = ARRAY_SIZE(mt6358_rtc_resources),
+   .resources = mt6358_rtc_resources,
+   .of_compatible = "mediatek,mt6358-rtc",
+   }, {
+   .name = "mt6359-sound",
+   .of_compatible = "mediatek,mt6359-sound",
+   },
+};
+
 static const struct mfd_cell mt6397_devs[] = {
{
.name = "mt6397-rtc",
@@ -149,6 +166,14 @@ static const struct chip_data mt6358_core = {
.irq_init = mt6358_irq_init,
 };
 
+static const struct chip_data mt6359_core = {
+   .cid_addr = MT6359_SWCID,
+   .cid_shift = 8,
+   .cells = mt6359_devs,
+   .cell_size = ARRAY_SIZE(mt6359_devs),
+   .irq_init = mt6358_irq_init,
+};
+
 static const struct chip_data mt6397_core = {
.cid_addr = MT6397_CID,
.cid_shift = 0,
@@ -218,6 +243,9 @@ static const struct of_device_id mt6397_of_match[] = {
}, {
.compatible = "mediatek,mt6358",
.data = _core,
+   }, {
+   .compatible = "mediatek,mt6359",
+   .data = _core,
}, {
.compatible = "mediatek,mt6397",
.data = _core,
diff --git a/include/linux/mfd/mt6359/core.h b/include/linux/mfd/mt6359/core.h
new file mode 100644
index ..61872f1ecbe4
--- /dev/null
+++ b/include/linux/mfd/mt6359/core.h
@@ -0,0 +1,133 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (c) 2020 MediaTek Inc.
+ */
+
+#ifndef __MFD_MT6359_CORE_H__
+#define __MFD_MT6359_CORE_H__
+
+enum mt6359_irq_top_status_shift {
+   MT6359_BUCK_TOP = 0,
+   MT6359_LDO_TOP,
+   MT6359_PSC_TOP,
+   MT6359_SCK_TOP,
+   MT6359_BM_TOP,
+   MT6359_HK_TOP,
+   MT6359_AUD_TOP = 7,
+   MT6359_MISC_TOP,
+};
+
+enum mt6359_irq_numbers {
+   MT6359_IRQ_VCORE_OC = 1,
+   MT6359_IRQ_VGPU11_OC,
+   MT6359_IRQ_VGPU12_OC,
+   MT6359_IRQ_VMODEM_OC,
+   MT6359_IRQ_VPROC1_OC,
+   MT6359_IRQ_VPROC2_OC,
+   MT6359_IRQ_VS1_OC,
+ 

[PATCH v4 4/9] dt-bindings: regulator: Add document for MT6359 regulator

2020-12-15 Thread Hsin-Hsiung Wang
add dt-binding document for MediaTek MT6359 PMIC

Signed-off-by: Hsin-Hsiung Wang 
---
 .../bindings/regulator/mt6359-regulator.yaml  | 169 ++
 1 file changed, 169 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml

diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
new file mode 100644
index ..09fd4cb90326
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -0,0 +1,169 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/mt6359-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MT6359 Regulator from MediaTek Integrated
+
+maintainers:
+  - Hsin-Hsiung Wang 
+
+description: |
+  List of regulators provided by this controller. It is named
+  according to its regulator type, buck_ and ldo_.
+  MT6359 regulators node should be sub node of the MT6397 MFD node.
+
+properties:
+  $nodename:
+pattern: "^pmic$"
+
+  mt6359regulator:
+type: object
+description:
+  list of regulators provided by this controller.
+
+patternProperties:
+  "^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$"
+
+unevaluatedProperties: false
+
+  "^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^v(ibr|rf12|usb|camio|efuse|xo22)$"
+
+unevaluatedProperties: false
+
+  "^ldo_v(rfck|emc|a12|a09|ufs|bbck)$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^v(rfck|emc|a12|a09|ufs|bbck)$"
+
+unevaluatedProperties: false
+
+  "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$"
+
+unevaluatedProperties: false
+
+  "^ldo_vsram_(proc2|others|md|proc1|others_sshub)$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^vsram_(proc2|others|md|proc1|others_sshub)$"
+
+unevaluatedProperties: false
+
+  "^ldo_v(fe|bif|io)28$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^v(fe|bif|io)28$"
+
+unevaluatedProperties: false
+
+  "^ldo_v(aud|io|aux|rf|m)18$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^v(aud|io|aux|rf|m)18$"
+
+unevaluatedProperties: false
+
+  "^ldo_vsim[12]$":
+type: object
+$ref: "regulator.yaml#"
+
+properties:
+  regulator-name:
+pattern: "^vsim[12]$"
+
+required:
+  - regulator-name
+
+unevaluatedProperties: false
+
+additionalProperties: false
+
+examples:
+  - |
+pmic {
+  mt6359regulator {
+mt6359_vgpu11_buck_reg: buck_vgpu11 {
+  regulator-name = "vgpu11";
+  regulator-min-microvolt = <40>;
+  regulator-max-microvolt = <1193750>;
+  regulator-enable-ramp-delay = <200>;
+  regulator-always-on;
+  regulator-allowed-modes = <0 1 2>;
+};
+
+mt6359_vcamio_ldo_reg: ldo_vcamio {
+  regulator-name = "vcamio";
+  regulator-min-microvolt = <170>;
+  regulator-max-microvolt = <190>;
+};
+
+mt6359_vcn18_ldo_reg: ldo_vcn18 {
+  regulator-name = "vcn18";
+  regulator-min-microvolt = <180>;
+  regulator-max-microvolt = <180>;
+  regulator-enable-ramp-delay = <240>;
+};
+
+mt6359_vsram_proc2_ldo_reg: ldo_vsram_proc2 {
+  regulator-name = "vsram_proc2";
+  regulator-min-microvolt = <50>;
+  regulator-max-microvolt = <1293750>;
+  regulator-ramp-delay = <7500>;
+  regulator-enable-ramp-delay = <240>;
+  regulator-always-on;
+};
+
+mt6359_vfe28_ldo_reg: ldo_vfe28 {
+  regulator-name = "vfe28";
+  regulator-min-microvolt = <280>;
+  regulator-max-microvolt = <280>;
+  regulator-enable-ramp-delay = <120>;
+};
+
+mt6359_vaud18_ldo_reg: ldo_vaud18 {
+  regulator-name = "vaud18";
+  regulator-min-microvolt = <180>;
+  regulator-max-microvolt = <180>;
+  regulator-enable-ramp-delay = <240>;
+};
+
+

[PATCH v4 3/9] dt-bindings: mfd: Add compatible for the MediaTek MT6359 PMIC

2020-12-15 Thread Hsin-Hsiung Wang
This adds compatible for the MediaTek MT6359 PMIC.

Signed-off-by: Hsin-Hsiung Wang 
---
 Documentation/devicetree/bindings/mfd/mt6397.txt | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt 
b/Documentation/devicetree/bindings/mfd/mt6397.txt
index 2661775a3825..2b4ad0902d42 100644
--- a/Documentation/devicetree/bindings/mfd/mt6397.txt
+++ b/Documentation/devicetree/bindings/mfd/mt6397.txt
@@ -21,6 +21,7 @@ Required properties:
 compatible:
"mediatek,mt6323" for PMIC MT6323
"mediatek,mt6358" for PMIC MT6358
+   "mediatek,mt6359" for PMIC MT6359
"mediatek,mt6397" for PMIC MT6397
 
 Optional subnodes:
@@ -37,11 +38,15 @@ Optional subnodes:
see ../regulator/mt6323-regulator.txt
- compatible: "mediatek,mt6358-regulator"
see ../regulator/mt6358-regulator.txt
+   - compatible: "mediatek,mt6359-regulator"
+   see ../regulator/mt6359-regulator.txt
- compatible: "mediatek,mt6397-regulator"
see ../regulator/mt6397-regulator.txt
 - codec
Required properties:
-   - compatible: "mediatek,mt6397-codec" or "mediatek,mt6358-sound"
+   - compatible: "mediatek,mt6397-codec"
+   - compatible: "mediatek,mt6358-sound"
+   - compatible: "mediatek,mt6359-sound"
 - clk
Required properties:
- compatible: "mediatek,mt6397-clk"
-- 
2.18.0



[PATCH v4 0/9] Add Support for MediaTek PMIC MT6359

2020-12-15 Thread Hsin-Hsiung Wang
This patchset includes refactoring interrupt and adding support to MT6359 PMIC.
MT6359 is the primary PMIC for MT6779 and probably other SOCs.
The series[1] sent by Wen will continue to upstream in this patchset afterwards.

[1] https://patchwork.kernel.org/project/linux-mediatek/list/?series=306579

changes since v3:
- fix yamllint errors in dt-binding document.
- remove unused compatible name of mt6359 codec in the dts.
- refine RTC_TC_MTH in the rtc-mt6397 driver to support new chips.
- add mt6359 rtc support.
- use regmap_get_voltage_sel_regmap() to get voltage instead of
  mt6359_get_linear_voltage_sel().

Hsin-Hsiung Wang (7):
  mfd: mt6358: refine interrupt code
  rtc: mt6397: refine RTC_TC_MTH
  dt-bindings: mfd: Add compatible for the MediaTek MT6359 PMIC
  dt-bindings: regulator: Add document for MT6359 regulator
  mfd: Add support for the MediaTek MT6359 PMIC
  regulator: mt6359: Set the enable time for LDOs
  regulator: mt6359: Add support for MT6359P regulator

Wen Su (2):
  regulator: mt6359: Add support for MT6359 regulator
  arm64: dts: mt6359: add PMIC MT6359 related nodes

 .../devicetree/bindings/mfd/mt6397.txt|7 +-
 .../bindings/regulator/mt6359-regulator.yaml  |  169 +++
 arch/arm64/boot/dts/mediatek/mt6359.dtsi  |  298 +
 drivers/mfd/mt6358-irq.c  |   89 +-
 drivers/mfd/mt6397-core.c |   28 +
 drivers/regulator/Kconfig |9 +
 drivers/regulator/Makefile|1 +
 drivers/regulator/mt6359-regulator.c  | 1035 +
 drivers/rtc/rtc-mt6397.c  |2 +-
 include/linux/mfd/mt6358/core.h   |8 +-
 include/linux/mfd/mt6359/core.h   |  133 +++
 include/linux/mfd/mt6359/registers.h  |  529 +
 include/linux/mfd/mt6359p/registers.h |  249 
 include/linux/mfd/mt6397/core.h   |1 +
 include/linux/mfd/mt6397/rtc.h|1 +
 include/linux/regulator/mt6359-regulator.h|   59 +
 16 files changed, 2584 insertions(+), 34 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
 create mode 100644 arch/arm64/boot/dts/mediatek/mt6359.dtsi
 create mode 100644 drivers/regulator/mt6359-regulator.c
 create mode 100644 include/linux/mfd/mt6359/core.h
 create mode 100644 include/linux/mfd/mt6359/registers.h
 create mode 100644 include/linux/mfd/mt6359p/registers.h
 create mode 100644 include/linux/regulator/mt6359-regulator.h

-- 
2.18.0



[PATCH v4 8/9] regulator: mt6359: Add support for MT6359P regulator

2020-12-15 Thread Hsin-Hsiung Wang
The MT6359P is a eco version for MT6359 regulator.
We add support based on MT6359 regulator driver.

Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/regulator/mt6359-regulator.c   | 377 -
 include/linux/mfd/mt6359p/registers.h  | 249 ++
 include/linux/regulator/mt6359-regulator.h |   1 +
 3 files changed, 622 insertions(+), 5 deletions(-)
 create mode 100644 include/linux/mfd/mt6359p/registers.h

diff --git a/drivers/regulator/mt6359-regulator.c 
b/drivers/regulator/mt6359-regulator.c
index e46fb95b87e2..42b958ced38a 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -4,6 +4,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -143,6 +144,28 @@ struct mt6359_regulator_info {
.qi = BIT(0),   \
 }
 
+#define MT6359P_LDO1(match, _name, _ops, _volt_table,  \
+   _enable_reg, _enable_mask, _status_reg, \
+   _vsel_reg, _vsel_mask)  \
+[MT6359_ID_##_name] = {\
+   .desc = {   \
+   .name = #_name, \
+   .of_match = of_match_ptr(match),\
+   .ops = &_ops,   \
+   .type = REGULATOR_VOLTAGE,  \
+   .id = MT6359_ID_##_name,\
+   .owner = THIS_MODULE,   \
+   .n_voltages = ARRAY_SIZE(_volt_table),  \
+   .volt_table = _volt_table,  \
+   .vsel_reg = _vsel_reg,  \
+   .vsel_mask = _vsel_mask,\
+   .enable_reg = _enable_reg,  \
+   .enable_mask = BIT(_enable_mask),   \
+   },  \
+   .status_reg = _status_reg,  \
+   .qi = BIT(0),   \
+}
+
 static const struct linear_range mt_volt_range1[] = {
REGULATOR_LINEAR_RANGE(80, 0, 0x70, 12500),
 };
@@ -171,6 +194,10 @@ static const struct linear_range mt_volt_range7[] = {
REGULATOR_LINEAR_RANGE(50, 0, 0x7f, 6250),
 };
 
+static const struct linear_range mt_volt_range8[] = {
+   REGULATOR_LINEAR_RANGE(506250, 0, 0x7f, 6250),
+};
+
 static const u32 vsim1_voltages[] = {
0, 0, 0, 170, 180, 0, 0, 0, 270, 0, 0, 300, 310,
 };
@@ -208,6 +235,10 @@ static const u32 vrfck_voltages[] = {
0, 0, 150, 0, 0, 0, 0, 160, 0, 0, 0, 0, 170,
 };
 
+static const u32 vrfck_voltages_1[] = {
+   124, 160,
+};
+
 static const u32 vio28_voltages[] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 280, 290, 300, 310, 330,
 };
@@ -216,6 +247,11 @@ static const u32 vemc_voltages[] = {
0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 290, 300, 0, 330,
 };
 
+static const u32 vemc_voltages_1[] = {
+   0, 0, 0, 0, 0, 0, 0, 0, 250, 280, 290, 300, 310,
+   330,
+};
+
 static const u32 va12_voltages[] = {
0, 0, 0, 0, 0, 0, 120, 130,
 };
@@ -352,6 +388,78 @@ static int mt6359_regulator_set_mode(struct regulator_dev 
*rdev,
return ret;
 }
 
+static int mt6359p_vemc_set_voltage_sel(struct regulator_dev *rdev,
+   u32 sel)
+{
+   struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+   int ret;
+   u32 val = 0;
+
+   sel <<= ffs(info->desc.vsel_mask) - 1;
+   ret = regmap_write(rdev->regmap, MT6359P_TMA_KEY_ADDR, TMA_KEY);
+   if (ret)
+   return ret;
+
+   ret = regmap_read(rdev->regmap, MT6359P_VM_MODE_ADDR, );
+   if (ret)
+   return ret;
+
+   switch (val) {
+   case 0:
+   /* If HW trapping is 0, use VEMC_VOSEL_0 */
+   ret = regmap_update_bits(rdev->regmap,
+info->desc.vsel_reg,
+info->desc.vsel_mask, sel);
+   break;
+   case 1:
+   /* If HW trapping is 1, use VEMC_VOSEL_1 */
+   ret = regmap_update_bits(rdev->regmap,
+info->desc.vsel_reg + 0x2,
+info->desc.vsel_mask, sel);
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   if (ret)
+   return ret;
+
+   ret = regmap_write(rdev->regmap, MT6359P_TMA_KEY_ADDR, 0);
+   return ret;
+}
+
+static int mt6359p_vemc_get_voltage_sel(struct regulator_dev *rdev)
+{
+   struct mt6359_regulator_info *info = rdev_get_drvdata(rdev);
+   int ret;
+   u32 val = 0;
+
+   ret = regmap_read(rdev->regmap, MT6359P_VM_MODE_ADDR, );
+   if (ret)
+   return ret;
+   switch (val) {
+   case 0:
+   /* If HW trapping is 0, use 

[PATCH v4 1/9] mfd: mt6358: refine interrupt code

2020-12-15 Thread Hsin-Hsiung Wang
This patch refines the interrupt related code to support new chips.

Signed-off-by: Hsin-Hsiung Wang 
Acked-for-MFD-by: Lee Jones 
---
 drivers/mfd/mt6358-irq.c| 65 +++--
 include/linux/mfd/mt6358/core.h |  8 ++--
 2 files changed, 41 insertions(+), 32 deletions(-)

diff --git a/drivers/mfd/mt6358-irq.c b/drivers/mfd/mt6358-irq.c
index db734f2831ff..4b094e5e51cc 100644
--- a/drivers/mfd/mt6358-irq.c
+++ b/drivers/mfd/mt6358-irq.c
@@ -13,7 +13,9 @@
 #include 
 #include 
 
-static struct irq_top_t mt6358_ints[] = {
+#define MTK_PMIC_REG_WIDTH 16
+
+static const struct irq_top_t mt6358_ints[] = {
MT6358_TOP_GEN(BUCK),
MT6358_TOP_GEN(LDO),
MT6358_TOP_GEN(PSC),
@@ -24,6 +26,13 @@ static struct irq_top_t mt6358_ints[] = {
MT6358_TOP_GEN(MISC),
 };
 
+static struct pmic_irq_data mt6358_irqd = {
+   .num_top = ARRAY_SIZE(mt6358_ints),
+   .num_pmic_irqs = MT6358_IRQ_NR,
+   .top_int_status_reg = MT6358_TOP_INT_STATUS0,
+   .pmic_ints = mt6358_ints,
+};
+
 static void pmic_irq_enable(struct irq_data *data)
 {
unsigned int hwirq = irqd_to_hwirq(data);
@@ -62,15 +71,15 @@ static void pmic_irq_sync_unlock(struct irq_data *data)
/* Find out the IRQ group */
top_gp = 0;
while ((top_gp + 1) < irqd->num_top &&
-  i >= mt6358_ints[top_gp + 1].hwirq_base)
+  i >= irqd->pmic_ints[top_gp + 1].hwirq_base)
top_gp++;
 
/* Find the IRQ registers */
-   gp_offset = i - mt6358_ints[top_gp].hwirq_base;
-   int_regs = gp_offset / MT6358_REG_WIDTH;
-   shift = gp_offset % MT6358_REG_WIDTH;
-   en_reg = mt6358_ints[top_gp].en_reg +
-(mt6358_ints[top_gp].en_reg_shift * int_regs);
+   gp_offset = i - irqd->pmic_ints[top_gp].hwirq_base;
+   int_regs = gp_offset / MTK_PMIC_REG_WIDTH;
+   shift = gp_offset % MTK_PMIC_REG_WIDTH;
+   en_reg = irqd->pmic_ints[top_gp].en_reg +
+(irqd->pmic_ints[top_gp].en_reg_shift * int_regs);
 
regmap_update_bits(chip->regmap, en_reg, BIT(shift),
   irqd->enable_hwirq[i] << shift);
@@ -95,10 +104,11 @@ static void mt6358_irq_sp_handler(struct mt6397_chip *chip,
unsigned int irq_status, sta_reg, status;
unsigned int hwirq, virq;
int i, j, ret;
+   struct pmic_irq_data *irqd = chip->irq_data;
 
-   for (i = 0; i < mt6358_ints[top_gp].num_int_regs; i++) {
-   sta_reg = mt6358_ints[top_gp].sta_reg +
-   mt6358_ints[top_gp].sta_reg_shift * i;
+   for (i = 0; i < irqd->pmic_ints[top_gp].num_int_regs; i++) {
+   sta_reg = irqd->pmic_ints[top_gp].sta_reg +
+   irqd->pmic_ints[top_gp].sta_reg_shift * i;
 
ret = regmap_read(chip->regmap, sta_reg, _status);
if (ret) {
@@ -114,8 +124,8 @@ static void mt6358_irq_sp_handler(struct mt6397_chip *chip,
do {
j = __ffs(status);
 
-   hwirq = mt6358_ints[top_gp].hwirq_base +
-   MT6358_REG_WIDTH * i + j;
+   hwirq = irqd->pmic_ints[top_gp].hwirq_base +
+   MTK_PMIC_REG_WIDTH * i + j;
 
virq = irq_find_mapping(chip->irq_domain, hwirq);
if (virq)
@@ -131,12 +141,12 @@ static void mt6358_irq_sp_handler(struct mt6397_chip 
*chip,
 static irqreturn_t mt6358_irq_handler(int irq, void *data)
 {
struct mt6397_chip *chip = data;
-   struct pmic_irq_data *mt6358_irq_data = chip->irq_data;
+   struct pmic_irq_data *irqd = chip->irq_data;
unsigned int bit, i, top_irq_status = 0;
int ret;
 
ret = regmap_read(chip->regmap,
- mt6358_irq_data->top_int_status_reg,
+ irqd->top_int_status_reg,
  _irq_status);
if (ret) {
dev_err(chip->dev,
@@ -144,8 +154,8 @@ static irqreturn_t mt6358_irq_handler(int irq, void *data)
return IRQ_NONE;
}
 
-   for (i = 0; i < mt6358_irq_data->num_top; i++) {
-   bit = BIT(mt6358_ints[i].top_offset);
+   for (i = 0; i < irqd->num_top; i++) {
+   bit = BIT(irqd->pmic_ints[i].top_offset);
if (top_irq_status & bit) {
mt6358_irq_sp_handler(chip, i);
top_irq_status &= ~bit;
@@ -180,17 +190,18 @@ int mt6358_irq_init(struct mt6397_chip *chip)
int i, j, ret;
struct pmic_irq_data *irqd;
 
-   irqd = devm_kzalloc(chip->dev, sizeof(*irqd), GFP_KERNEL);
-   if (!irqd)
-   return -ENOMEM;
+   switch (chip->chip_id) {
+   case MT6358_CHIP_ID:
+   chip->irq_data 

[PATCH v4 2/9] rtc: mt6397: refine RTC_TC_MTH

2020-12-15 Thread Hsin-Hsiung Wang
This patch adds RTC_TC_MTH_MASK to support new chips.

Signed-off-by: Yuchen Huang 
Signed-off-by: Hsin-Hsiung Wang 
---
 drivers/rtc/rtc-mt6397.c   | 2 +-
 include/linux/mfd/mt6397/rtc.h | 1 +
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-mt6397.c b/drivers/rtc/rtc-mt6397.c
index 1894aded4c85..ea6da7476a5e 100644
--- a/drivers/rtc/rtc-mt6397.c
+++ b/drivers/rtc/rtc-mt6397.c
@@ -75,7 +75,7 @@ static int __mtk_rtc_read_time(struct mt6397_rtc *rtc,
tm->tm_min = data[RTC_OFFSET_MIN];
tm->tm_hour = data[RTC_OFFSET_HOUR];
tm->tm_mday = data[RTC_OFFSET_DOM];
-   tm->tm_mon = data[RTC_OFFSET_MTH];
+   tm->tm_mon = data[RTC_OFFSET_MTH] & RTC_TC_MTH_MASK;
tm->tm_year = data[RTC_OFFSET_YEAR];
 
ret = regmap_read(rtc->regmap, rtc->addr_base + RTC_TC_SEC, sec);
diff --git a/include/linux/mfd/mt6397/rtc.h b/include/linux/mfd/mt6397/rtc.h
index c3748b53bf7d..068ae1c0f0e8 100644
--- a/include/linux/mfd/mt6397/rtc.h
+++ b/include/linux/mfd/mt6397/rtc.h
@@ -36,6 +36,7 @@
 #define RTC_AL_MASK_DOWBIT(4)
 
 #define RTC_TC_SEC 0x000a
+#define RTC_TC_MTH_MASK0x000f
 /* Min, Hour, Dom... register offset to RTC_TC_SEC */
 #define RTC_OFFSET_SEC 0
 #define RTC_OFFSET_MIN 1
-- 
2.18.0



[GIT PULL] MFD for v5.11

2020-12-15 Thread Lee Jones
Good morning Linus,

The following changes since commit 3650b228f83adda7e5ee532e2b90429c03f7b9ec:

  Linux 5.10-rc1 (2020-10-25 15:14:11 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git mfd-next-5.11

for you to fetch changes up to 0cd3aa995740eabf8af1c794ac1d9ae314c928c3:

  mfd: kempld-core: Add support for additional devices (2020-12-02 12:53:27 
+)


 - New Drivers
   - Add support for Intel's Platform Monitoring Technology (PMT)

 - New Device Support
   - Add support for PM660/PM660L to QCom SPMI PMIC
   - Add support for lots of new devices to Kontron Core

 - New Functionality
   - Provide syscon_regmap_lookup_by_phandle_optional() to SysCon API

 - Fix-ups
   - Constify; da9xxx-core; intel_*, tps65xxx, wm8xxx-core, lp8788,
   stmpe, sun4i-gpadc, 88pm800, hi655x-pmic, ioc3, etc
   - Remove superfluous code; madera, tps65910
   - Use raw APIs (rid abstractions); tps65911-comparator, tps65910
   - Whitespace/formatting fix-ups; tps65910
   - Device Tree changes/updates; bd71837-pmic, syscon
   - Use helpers/APIs (no hand rolling); altera-sysmgr
   - Mark of_match tables as __maybe_unused; twl6030-irq
   - Fix spelling; si476x-core

 - Bug Fixes
   - Reset on resume to ensure known state; madera-core
   - Correct ordering issues; madera-core, tps65910, kempld-core
   - Remove erroneous passing of of_compatible strings; at91-usart
   - Fix potential I2C adaptor leak; htc-i2cpld
   - Correct errorneous defines; rt5033-private
   - Resolve Kconfig issues; MFD_SL28CPLD, MFD_OMAP_USB_HOST
   - Fix dev_err_probe() handling; stmfx
   - Repair interrupt regression; motorola-cpcap
   - Allow ACPI matching of DT tables; bcm590xx, da9xx, ene-kb3930,
   fsl-imx25-tsadc, max77650,
   mt6397-core, rt5033, stmfx,
   max77686, sun4i-gpadc,
   wm8994-core, axp20x-i2c


Alexander Duyck (3):
  platform/x86: Intel PMT class driver
  platform/x86: Intel PMT Telemetry capability driver
  platform/x86: Intel PMT Crashlog capability driver

Amelie Delaunay (1):
  mfd: stmfx: Fix dev_err_probe() call in stmfx_chip_init()

AngeloGioacchino Del Regno (1):
  mfd: qcom-spmi-pmic: Add support for PM660/PM660L

Charles Keepax (2):
  mfd: madera: Add reset as part of resume
  mfd: madera: Add special errata reset handling for cs47l15

Codrin Ciubotariu (1):
  mfd: at91-usart: Do not use compatible to register child devices

David E. Box (2):
  PCI: Add defines for Designated Vendor-Specific Extended Capability
  mfd: Intel Platform Monitoring Technology support

Dmitry Osipenko (1):
  mfd: tps65910: Correct power-off programming sequence

Enric Balletbo i Serra (1):
  mfd: syscon: Add syscon_regmap_lookup_by_phandle_optional() function.

Geert Uytterhoeven (1):
  mfd: MFD_SL28CPLD should depend on ARCH_LAYERSCAPE

Jing Xiangfeng (1):
  mfd: htc-i2cpld: Add the missed i2c_put_adapter() in 
htcpld_register_chip_i2c()

Johan Jonker (1):
  dt-binding: mfd: syscon: add Rockchip QoS register compatibles

Krzysztof Kozlowski (18):
  dt-bindings: mfd: rohm,bd71837-pmic: Add common properties
  mfd: omap-usb: Depend on COMMON_CLK to fix compile tests
  mfd: bcm590xx: Drop of_match_ptr from of_device_id table
  mfd: da9055: Drop of_match_ptr from of_device_id table
  mfd: da9062: Drop of_match_ptr from of_device_id table
  mfd: da9063: Drop of_match_ptr from of_device_id table
  mfd: da9150: Drop of_match_ptr from of_device_id table
  mfd: ene-kb3930: Drop of_match_ptr from of_device_id table
  mfd: fsl-imx25: Drop of_match_ptr from of_device_id table
  mfd: max77650: Drop of_match_ptr from of_device_id table
  mfd: mt6397: Drop of_match_ptr from of_device_id table
  mfd: rt5033: Drop of_match_ptr from of_device_id table
  mfd: stmfx: Drop of_match_ptr from of_device_id table
  mfd: max77686: Drop of_match_ptr from of_device_id table
  mfd: sun4i: Drop of_match_ptr from of_device_id table
  mfd: wm8994: Drop of_match_ptr from of_device_id table
  mfd: axp20x: Skip of_device_id table when !CONFIG_OF
  mfd: twl6030: Mark of_device_id table as maybe unused

Lee Jones (2):
  Merge branch 'ib-mfd-mediatek-5.11' into ibs-for-mfd-merged
  mfd: tps65910: Fix a bunch of alignment issues reported-by Checkpatch

Michael Brunner (2):
  mfd: kempld-core: Check for DMI definition before ACPI
  mfd: kempld-core: Add support for additional devices

Michael Klein (1):
  mfd: si476x-core.h: Fix "regulator" spelling in comment

Michael Srba (1):
  mfd: rt5033: Fix errorneous defines

Michał Mirosław (4):
  mfd: tps65911-comparator: Use regmap accessors
  

Re: [PATCH] dt-bindings: display: bridge: tc358768: Remove maintainer information

2020-12-15 Thread Peter Ujfalusi


On 15/12/2020 16.26, Rob Herring wrote:
> On Tue, 15 Dec 2020 14:42:27 +0200, Peter Ujfalusi wrote:
>> My employment with TI is coming to an end and I will not have access to
>> the board where this bridge is connected to.
>>
>> It is better to remove a soon bouncing email address.
>>
>> Signed-off-by: Peter Ujfalusi 
>> ---
>>  .../devicetree/bindings/display/bridge/toshiba,tc358768.yaml   | 3 ---
>>  1 file changed, 3 deletions(-)
>>
> 
> My bot found errors running 'make dt_binding_check' on your patch:
> 
> yamllint warnings/errors:
> 
> dtschema/dtc warnings/errors:
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>  'maintainers' is a required property
> /builds/robherring/linux-dt-review/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml:
>  ignoring, error in schema: 
> warning: no schema found in file: 
> ./Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml

Right, so it is not that easy to not been able to maintain this... :o

Who should be documented as maintainer?
Andrzej, Neil, David or Daniel?

I will have no access to the EVM (I no longer have) and the
documentation is going to be wiped along with the disk as well...

> See https://patchwork.ozlabs.org/patch/1416419
> 
> This check can fail if there are any dependencies. The base for a patch
> series is generally the most recent rc1.
> 
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
> 
> pip3 install dtschema --upgrade
> 
> Please check and re-submit.
> 

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


[PATCH v3 02/12] dt-bindings: mfd: bd9571mwv: Document BD9574MWF

2020-12-15 Thread Yoshihiro Shimoda
Document other similar specification chip BD9574MWF.

Signed-off-by: Yoshihiro Shimoda 
---
 Documentation/devicetree/bindings/mfd/bd9571mwv.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt 
b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
index 8c46786..1d6413e 100644
--- a/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
+++ b/Documentation/devicetree/bindings/mfd/bd9571mwv.txt
@@ -1,7 +1,7 @@
-* ROHM BD9571MWV Power Management Integrated Circuit (PMIC) bindings
+* ROHM BD9571MWV/BD9574MWF Power Management Integrated Circuit (PMIC) bindings
 
 Required properties:
- - compatible  : Should be "rohm,bd9571mwv".
+ - compatible  : Should be "rohm,bd9571mwv" or "rohm,bd9574mwf".
  - reg : I2C slave address.
  - interrupts  : The interrupt line the device is connected to.
  - interrupt-controller: Marks the device node as an interrupt 
controller.
-- 
2.7.4



[PATCH v3 04/12] regulator: bd9571mwv: rid of using struct bd9571mwv

2020-12-15 Thread Yoshihiro Shimoda
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Matti Vaittinen 
---
 drivers/regulator/bd9571mwv-regulator.c | 49 +
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index e690c2c..42b6a70 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -17,7 +17,7 @@
 #include 
 
 struct bd9571mwv_reg {
-   struct bd9571mwv *bd;
+   struct regmap *regmap;
 
/* DDR Backup Power */
u8 bkup_mode_cnt_keepon;/* from "rohm,ddr-backup-power" */
@@ -137,26 +137,30 @@ static const struct regulator_desc regulators[] = {
 };
 
 #ifdef CONFIG_PM_SLEEP
-static int bd9571mwv_bkup_mode_read(struct bd9571mwv *bd, unsigned int *mode)
+static int bd9571mwv_bkup_mode_read(struct bd9571mwv_reg *bdreg,
+   unsigned int *mode)
 {
int ret;
 
-   ret = regmap_read(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+   ret = regmap_read(bdreg->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
if (ret) {
-   dev_err(bd->dev, "failed to read backup mode (%d)\n", ret);
+   dev_err(regmap_get_device(bdreg->regmap),
+   "failed to read backup mode (%d)\n", ret);
return ret;
}
 
return 0;
 }
 
-static int bd9571mwv_bkup_mode_write(struct bd9571mwv *bd, unsigned int mode)
+static int bd9571mwv_bkup_mode_write(struct bd9571mwv_reg *bdreg,
+unsigned int mode)
 {
int ret;
 
-   ret = regmap_write(bd->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
+   ret = regmap_write(bdreg->regmap, BD9571MWV_BKUP_MODE_CNT, mode);
if (ret) {
-   dev_err(bd->dev, "failed to configure backup mode 0x%x (%d)\n",
+   dev_err(regmap_get_device(bdreg->regmap),
+   "failed to configure backup mode 0x%x (%d)\n",
mode, ret);
return ret;
}
@@ -194,7 +198,7 @@ static ssize_t backup_mode_store(struct device *dev,
 * Configure DDR Backup Mode, to change the role of the accessory power
 * switch from a power switch to a wake-up switch, or vice versa
 */
-   ret = bd9571mwv_bkup_mode_read(bdreg->bd, );
+   ret = bd9571mwv_bkup_mode_read(bdreg, );
if (ret)
return ret;
 
@@ -202,7 +206,7 @@ static ssize_t backup_mode_store(struct device *dev,
if (bdreg->bkup_mode_enabled)
mode |= bdreg->bkup_mode_cnt_keepon;
 
-   ret = bd9571mwv_bkup_mode_write(bdreg->bd, mode);
+   ret = bd9571mwv_bkup_mode_write(bdreg, mode);
if (ret)
return ret;
 
@@ -221,7 +225,7 @@ static int bd9571mwv_suspend(struct device *dev)
return 0;
 
/* Save DDR Backup Mode */
-   ret = bd9571mwv_bkup_mode_read(bdreg->bd, );
+   ret = bd9571mwv_bkup_mode_read(bdreg, );
if (ret)
return ret;
 
@@ -235,7 +239,7 @@ static int bd9571mwv_suspend(struct device *dev)
mode |= bdreg->bkup_mode_cnt_keepon;
 
if (mode != bdreg->bkup_mode_cnt_saved)
-   return bd9571mwv_bkup_mode_write(bdreg->bd, mode);
+   return bd9571mwv_bkup_mode_write(bdreg, mode);
 
return 0;
 }
@@ -248,7 +252,7 @@ static int bd9571mwv_resume(struct device *dev)
return 0;
 
/* Restore DDR Backup Mode */
-   return bd9571mwv_bkup_mode_write(bdreg->bd, bdreg->bkup_mode_cnt_saved);
+   return bd9571mwv_bkup_mode_write(bdreg, bdreg->bkup_mode_cnt_saved);
 }
 
 static const struct dev_pm_ops bd9571mwv_pm  = {
@@ -268,7 +272,6 @@ static int bd9571mwv_regulator_remove(struct 
platform_device *pdev)
 
 static int bd9571mwv_regulator_probe(struct platform_device *pdev)
 {
-   struct bd9571mwv *bd = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = { };
struct bd9571mwv_reg *bdreg;
struct regulator_dev *rdev;
@@ -279,40 +282,40 @@ static int bd9571mwv_regulator_probe(struct 
platform_device *pdev)
if (!bdreg)
return -ENOMEM;
 
-   bdreg->bd = bd;
+   bdreg->regmap = dev_get_regmap(pdev->dev.parent, NULL);
 
platform_set_drvdata(pdev, bdreg);
 
config.dev = >dev;
-   config.dev->of_node = bd->dev->of_node;
-   config.driver_data = bd;
-   config.regmap = bd->regmap;
+   config.dev->of_node = pdev->dev.parent->of_node;
+   config.driver_data = bdreg;
+   config.regmap = bdreg->regmap;
 
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
rdev = devm_regulator_register(>dev, [i],
   );
if (IS_ERR(rdev)) {
-   dev_err(bd->dev, "failed to register %s regulator\n",
+

[PATCH v3 12/12] mfd: bd9571mwv: Add support for BD9574MWF

2020-12-15 Thread Yoshihiro Shimoda
From: Khiem Nguyen 

The new PMIC BD9574MWF inherits features from BD9571MWV.
Add the support of new PMIC to existing bd9571mwv driver.

Signed-off-by: Khiem Nguyen 
[shimoda: rebase and refactor]
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mfd/bd9571mwv.c   | 86 ++-
 include/linux/mfd/bd9571mwv.h | 18 +++--
 2 files changed, 99 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index ccf1a60..f660de6 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * ROHM BD9571MWV-M MFD driver
+ * ROHM BD9571MWV-M and BD9574MVF-M MFD driver
  *
  * Copyright (C) 2017 Marek Vasut 
  * Copyright (C) 2020 Renesas Electronics Corporation
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -28,6 +29,7 @@ struct bd957x_data {
int num_cells;
 };
 
+/* For BD9571MWV */
 static const struct mfd_cell bd9571mwv_cells[] = {
{ .name = "bd9571mwv-regulator", },
{ .name = "bd9571mwv-gpio", },
@@ -124,6 +126,81 @@ static const struct bd957x_data bd9571mwv_data = {
.num_cells = ARRAY_SIZE(bd9571mwv_cells),
 };
 
+/* For BD9574MWF */
+static const struct mfd_cell bd9574mwf_cells[] = {
+   { .name = "bd9574mwf-regulator", },
+   { .name = "bd9574mwf-gpio", },
+};
+
+static const struct regmap_range bd9574mwf_readable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_VENDOR_CODE, BD9571MWV_PRODUCT_REVISION),
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
+   regmap_reg_range(BD9571MWV_DVFS_VINIT, BD9571MWV_DVFS_SETVMAX),
+   regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_MONIVDAC),
+   regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
+   regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INTMASK),
+   regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK),
+};
+
+static const struct regmap_access_table bd9574mwf_readable_table = {
+   .yes_ranges = bd9574mwf_readable_yes_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(bd9574mwf_readable_yes_ranges),
+};
+
+static const struct regmap_range bd9574mwf_writable_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_BKUP_MODE_CNT, BD9571MWV_BKUP_MODE_CNT),
+   regmap_reg_range(BD9571MWV_DVFS_SETVID, BD9571MWV_DVFS_SETVID),
+   regmap_reg_range(BD9571MWV_GPIO_DIR, BD9571MWV_GPIO_OUT),
+   regmap_reg_range(BD9571MWV_GPIO_INT_SET, BD9571MWV_GPIO_INTMASK),
+   regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTMASK),
+};
+
+static const struct regmap_access_table bd9574mwf_writable_table = {
+   .yes_ranges = bd9574mwf_writable_yes_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(bd9574mwf_writable_yes_ranges),
+};
+
+static const struct regmap_range bd9574mwf_volatile_yes_ranges[] = {
+   regmap_reg_range(BD9571MWV_DVFS_MONIVDAC, BD9571MWV_DVFS_MONIVDAC),
+   regmap_reg_range(BD9571MWV_GPIO_IN, BD9571MWV_GPIO_IN),
+   regmap_reg_range(BD9571MWV_GPIO_INT, BD9571MWV_GPIO_INT),
+   regmap_reg_range(BD9571MWV_INT_INTREQ, BD9571MWV_INT_INTREQ),
+};
+
+static const struct regmap_access_table bd9574mwf_volatile_table = {
+   .yes_ranges = bd9574mwf_volatile_yes_ranges,
+   .n_yes_ranges   = ARRAY_SIZE(bd9574mwf_volatile_yes_ranges),
+};
+
+static const struct regmap_config bd9574mwf_regmap_config = {
+   .reg_bits   = 8,
+   .val_bits   = 8,
+   .cache_type = REGCACHE_RBTREE,
+   .rd_table   = _readable_table,
+   .wr_table   = _writable_table,
+   .volatile_table = _volatile_table,
+   .max_register   = 0xff,
+};
+
+static struct regmap_irq_chip bd9574mwf_irq_chip = {
+   .name   = "bd9574mwf",
+   .status_base= BD9571MWV_INT_INTREQ,
+   .mask_base  = BD9571MWV_INT_INTMASK,
+   .ack_base   = BD9571MWV_INT_INTREQ,
+   .init_ack_masked = true,
+   .num_regs   = 1,
+   .irqs   = bd9571mwv_irqs,
+   .num_irqs   = ARRAY_SIZE(bd9571mwv_irqs),
+};
+
+static const struct bd957x_data bd9574mwf_data = {
+   .part_name = BD9574MWF_PART_NAME,
+   .regmap_config = _regmap_config,
+   .irq_chip = _irq_chip,
+   .cells = bd9574mwf_cells,
+   .num_cells = ARRAY_SIZE(bd9574mwf_cells),
+};
+
 static int bd9571mwv_identify(struct device *dev, struct regmap *regmap,
  const char *part_name)
 {
@@ -181,6 +258,9 @@ static int bd9571mwv_probe(struct i2c_client *client,
case BD9571MWV_PRODUCT_CODE_VAL:
data = _data;
break;
+   case BD9574MWF_PRODUCT_CODE_VAL:
+   data = _data;
+   break;
default:
dev_err(dev, "Unsupported device 0x%x\n", ret);
return -ENOENT;
@@ -210,12 +290,14 @@ static int bd9571mwv_probe(struct i2c_client *client,
 
 static const struct of_device_id 

[PATCH v3 09/12] mfd: bd9571mwv: Use the SPDX license identifier

2020-12-15 Thread Yoshihiro Shimoda
Use the SPDX license identifier instead of a local description.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/mfd/bd9571mwv.c   | 10 +-
 include/linux/mfd/bd9571mwv.h | 10 +-
 2 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 19d57a4..e68c3fa 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -1,17 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ROHM BD9571MWV-M MFD driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
- * 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.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether expressed or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License version 2 for more details.
- *
  * Based on the TPS65086 driver
  */
 
diff --git a/include/linux/mfd/bd9571mwv.h b/include/linux/mfd/bd9571mwv.h
index eb05569..bcc7092 100644
--- a/include/linux/mfd/bd9571mwv.h
+++ b/include/linux/mfd/bd9571mwv.h
@@ -1,17 +1,9 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
 /*
  * ROHM BD9571MWV-M driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
- * 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.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether expressed or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License version 2 for more details.
- *
  * Based on the TPS65086 driver
  */
 
-- 
2.7.4



[PATCH v3 10/12] mfd: bd9571mwv: Use devm_regmap_add_irq_chip()

2020-12-15 Thread Yoshihiro Shimoda
Use dev_regmap_add_irq_chip() to simplify the code.

Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mfd/bd9571mwv.c | 27 ++-
 1 file changed, 6 insertions(+), 21 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index e68c3fa..49e968e 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -170,31 +170,17 @@ static int bd9571mwv_probe(struct i2c_client *client,
if (ret)
return ret;
 
-   ret = regmap_add_irq_chip(bd->regmap, bd->irq, IRQF_ONESHOT, 0,
- _irq_chip, >irq_data);
+   ret = devm_regmap_add_irq_chip(bd->dev, bd->regmap, bd->irq,
+  IRQF_ONESHOT, 0, _irq_chip,
+  >irq_data);
if (ret) {
dev_err(bd->dev, "Failed to register IRQ chip\n");
return ret;
}
 
-   ret = devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
-  bd9571mwv_cells, ARRAY_SIZE(bd9571mwv_cells),
-  NULL, 0, 
regmap_irq_get_domain(bd->irq_data));
-   if (ret) {
-   regmap_del_irq_chip(bd->irq, bd->irq_data);
-   return ret;
-   }
-
-   return 0;
-}
-
-static int bd9571mwv_remove(struct i2c_client *client)
-{
-   struct bd9571mwv *bd = i2c_get_clientdata(client);
-
-   regmap_del_irq_chip(bd->irq, bd->irq_data);
-
-   return 0;
+   return devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
+   bd9571mwv_cells, 
ARRAY_SIZE(bd9571mwv_cells),
+   NULL, 0, 
regmap_irq_get_domain(bd->irq_data));
 }
 
 static const struct of_device_id bd9571mwv_of_match_table[] = {
@@ -215,7 +201,6 @@ static struct i2c_driver bd9571mwv_driver = {
.of_match_table = bd9571mwv_of_match_table,
},
.probe  = bd9571mwv_probe,
-   .remove = bd9571mwv_remove,
.id_table   = bd9571mwv_id_table,
 };
 module_i2c_driver(bd9571mwv_driver);
-- 
2.7.4



[PATCH v3 08/12] gpio: bd9571mwv: Add BD9574MWF support

2020-12-15 Thread Yoshihiro Shimoda
Add support for BD9574MWF which is silimar chip with BD9571MWV.
Note that BD9574MWF has additional features "RECOV_GPOUT",
"FREQSEL" and "RTC_IN", but supports GPIO function only.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Matti Vaittinen 
---
 drivers/gpio/gpio-bd9571mwv.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index 0e5395f..df6102b 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * ROHM BD9571MWV-M GPIO driver
+ * ROHM BD9571MWV-M and BD9574MWF-M GPIO driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
@@ -10,6 +10,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 
@@ -118,7 +119,8 @@ static int bd9571mwv_gpio_probe(struct platform_device 
*pdev)
 }
 
 static const struct platform_device_id bd9571mwv_gpio_id_table[] = {
-   { "bd9571mwv-gpio", },
+   { "bd9571mwv-gpio", ROHM_CHIP_TYPE_BD9571 },
+   { "bd9574mwf-gpio", ROHM_CHIP_TYPE_BD9574 },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(platform, bd9571mwv_gpio_id_table);
-- 
2.7.4



[PATCH v3 11/12] mfd: bd9571mwv: Make the driver more generic

2020-12-15 Thread Yoshihiro Shimoda
From: Khiem Nguyen 

Since the driver supports BD9571MWV PMIC only,
this patch makes the functions and data structure become more generic
so that it can support other PMIC variants as well.

Signed-off-by: Khiem Nguyen 
[shimoda: rebase and refactor]
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mfd/bd9571mwv.c   | 95 +++
 include/linux/mfd/bd9571mwv.h | 18 ++--
 2 files changed, 63 insertions(+), 50 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index 49e968e..ccf1a60 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -3,6 +3,7 @@
  * ROHM BD9571MWV-M MFD driver
  *
  * Copyright (C) 2017 Marek Vasut 
+ * Copyright (C) 2020 Renesas Electronics Corporation
  *
  * Based on the TPS65086 driver
  */
@@ -14,6 +15,19 @@
 
 #include 
 
+/**
+ * struct bd957x_data - internal data for the bd957x driver
+ *
+ * Internal data to distinguish bd957x variants
+ */
+struct bd957x_data {
+   char *part_name;
+   const struct regmap_config *regmap_config;
+   const struct regmap_irq_chip *irq_chip;
+   const struct mfd_cell *cells;
+   int num_cells;
+};
+
 static const struct mfd_cell bd9571mwv_cells[] = {
{ .name = "bd9571mwv-regulator", },
{ .name = "bd9571mwv-gpio", },
@@ -102,13 +116,21 @@ static struct regmap_irq_chip bd9571mwv_irq_chip = {
.num_irqs   = ARRAY_SIZE(bd9571mwv_irqs),
 };
 
-static int bd9571mwv_identify(struct bd9571mwv *bd)
+static const struct bd957x_data bd9571mwv_data = {
+   .part_name = BD9571MWV_PART_NAME,
+   .regmap_config = _regmap_config,
+   .irq_chip = _irq_chip,
+   .cells = bd9571mwv_cells,
+   .num_cells = ARRAY_SIZE(bd9571mwv_cells),
+};
+
+static int bd9571mwv_identify(struct device *dev, struct regmap *regmap,
+ const char *part_name)
 {
-   struct device *dev = bd->dev;
unsigned int value;
int ret;
 
-   ret = regmap_read(bd->regmap, BD9571MWV_VENDOR_CODE, );
+   ret = regmap_read(regmap, BD9571MWV_VENDOR_CODE, );
if (ret) {
dev_err(dev, "Failed to read vendor code register (ret=%i)\n",
ret);
@@ -121,27 +143,20 @@ static int bd9571mwv_identify(struct bd9571mwv *bd)
return -EINVAL;
}
 
-   ret = regmap_read(bd->regmap, BD9571MWV_PRODUCT_CODE, );
+   ret = regmap_read(regmap, BD9571MWV_PRODUCT_CODE, );
if (ret) {
dev_err(dev, "Failed to read product code register (ret=%i)\n",
ret);
return ret;
}
-
-   if (value != BD9571MWV_PRODUCT_CODE_VAL) {
-   dev_err(dev, "Invalid product code ID %02x (expected %02x)\n",
-   value, BD9571MWV_PRODUCT_CODE_VAL);
-   return -EINVAL;
-   }
-
-   ret = regmap_read(bd->regmap, BD9571MWV_PRODUCT_REVISION, );
+   ret = regmap_read(regmap, BD9571MWV_PRODUCT_REVISION, );
if (ret) {
dev_err(dev, "Failed to read revision register (ret=%i)\n",
ret);
return ret;
}
 
-   dev_info(dev, "Device: BD9571MWV rev. %d\n", value & 0xff);
+   dev_info(dev, "Device: %s rev. %d\n", part_name, value & 0xff);
 
return 0;
 }
@@ -149,38 +164,48 @@ static int bd9571mwv_identify(struct bd9571mwv *bd)
 static int bd9571mwv_probe(struct i2c_client *client,
  const struct i2c_device_id *ids)
 {
-   struct bd9571mwv *bd;
-   int ret;
-
-   bd = devm_kzalloc(>dev, sizeof(*bd), GFP_KERNEL);
-   if (!bd)
-   return -ENOMEM;
-
-   i2c_set_clientdata(client, bd);
-   bd->dev = >dev;
-   bd->irq = client->irq;
+   const struct bd957x_data *data;
+   struct device *dev = >dev;
+   struct regmap *regmap;
+   struct regmap_irq_chip_data *irq_data;
+   int ret, irq = client->irq;
+
+   /* Read the PMIC product code */
+   ret = i2c_smbus_read_byte_data(client, BD9571MWV_PRODUCT_CODE);
+   if (ret < 0) {
+   dev_err(dev, "failed reading at 0x%02x\n",
+   BD9571MWV_PRODUCT_CODE);
+   return ret;
+   }
+   switch (ret) {
+   case BD9571MWV_PRODUCT_CODE_VAL:
+   data = _data;
+   break;
+   default:
+   dev_err(dev, "Unsupported device 0x%x\n", ret);
+   return -ENOENT;
+   }
 
-   bd->regmap = devm_regmap_init_i2c(client, _regmap_config);
-   if (IS_ERR(bd->regmap)) {
-   dev_err(bd->dev, "Failed to initialize register map\n");
-   return PTR_ERR(bd->regmap);
+   regmap = devm_regmap_init_i2c(client, data->regmap_config);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "Failed to initialize register map\n");
+   return PTR_ERR(regmap);
}
 
-   ret = bd9571mwv_identify(bd);
+   ret = 

[PATCH v3 07/12] gpio: bd9571mwv: rid of using struct bd9571mwv

2020-12-15 Thread Yoshihiro Shimoda
To simplify this driver, use dev_get_regmap() and
rid of using struct bd9571mwv.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Matti Vaittinen 
---
 drivers/gpio/gpio-bd9571mwv.c | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index abb622c..0e5395f 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -16,8 +16,8 @@
 #include 
 
 struct bd9571mwv_gpio {
+   struct regmap *regmap;
struct gpio_chip chip;
-   struct bd9571mwv *bd;
 };
 
 static int bd9571mwv_gpio_get_direction(struct gpio_chip *chip,
@@ -26,7 +26,7 @@ static int bd9571mwv_gpio_get_direction(struct gpio_chip 
*chip,
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
int ret, val;
 
-   ret = regmap_read(gpio->bd->regmap, BD9571MWV_GPIO_DIR, );
+   ret = regmap_read(gpio->regmap, BD9571MWV_GPIO_DIR, );
if (ret < 0)
return ret;
if (val & BIT(offset))
@@ -40,8 +40,7 @@ static int bd9571mwv_gpio_direction_input(struct gpio_chip 
*chip,
 {
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
 
-   regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_DIR,
-  BIT(offset), 0);
+   regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_DIR, BIT(offset), 0);
 
return 0;
 }
@@ -52,9 +51,9 @@ static int bd9571mwv_gpio_direction_output(struct gpio_chip 
*chip,
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
 
/* Set the initial value */
-   regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_OUT,
+   regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_OUT,
   BIT(offset), value ? BIT(offset) : 0);
-   regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_DIR,
+   regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_DIR,
   BIT(offset), BIT(offset));
 
return 0;
@@ -65,7 +64,7 @@ static int bd9571mwv_gpio_get(struct gpio_chip *chip, 
unsigned int offset)
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
int ret, val;
 
-   ret = regmap_read(gpio->bd->regmap, BD9571MWV_GPIO_IN, );
+   ret = regmap_read(gpio->regmap, BD9571MWV_GPIO_IN, );
if (ret < 0)
return ret;
 
@@ -77,7 +76,7 @@ static void bd9571mwv_gpio_set(struct gpio_chip *chip, 
unsigned int offset,
 {
struct bd9571mwv_gpio *gpio = gpiochip_get_data(chip);
 
-   regmap_update_bits(gpio->bd->regmap, BD9571MWV_GPIO_OUT,
+   regmap_update_bits(gpio->regmap, BD9571MWV_GPIO_OUT,
   BIT(offset), value ? BIT(offset) : 0);
 }
 
@@ -105,9 +104,9 @@ static int bd9571mwv_gpio_probe(struct platform_device 
*pdev)
 
platform_set_drvdata(pdev, gpio);
 
-   gpio->bd = dev_get_drvdata(pdev->dev.parent);
+   gpio->regmap = dev_get_regmap(pdev->dev.parent, NULL);
gpio->chip = template_chip;
-   gpio->chip.parent = gpio->bd->dev;
+   gpio->chip.parent = pdev->dev.parent;
 
ret = devm_gpiochip_add_data(>dev, >chip, gpio);
if (ret < 0) {
-- 
2.7.4



[PATCH v3 06/12] gpio: bd9571mwv: Use the SPDX license identifier

2020-12-15 Thread Yoshihiro Shimoda
Use the SPDX license identifier instead of a local description.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
---
 drivers/gpio/gpio-bd9571mwv.c | 10 +-
 1 file changed, 1 insertion(+), 9 deletions(-)

diff --git a/drivers/gpio/gpio-bd9571mwv.c b/drivers/gpio/gpio-bd9571mwv.c
index c0abc9c..abb622c 100644
--- a/drivers/gpio/gpio-bd9571mwv.c
+++ b/drivers/gpio/gpio-bd9571mwv.c
@@ -1,17 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-only
 /*
  * ROHM BD9571MWV-M GPIO driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
- * 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.
- *
- * This program is distributed "as is" WITHOUT ANY WARRANTY of any
- * kind, whether expressed or implied; without even the implied warranty
- * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License version 2 for more details.
- *
  * Based on the TPS65086 driver
  *
  * NOTE: Interrupts are not supported yet.
-- 
2.7.4



[PATCH v3 05/12] regulator: bd9571mwv: Add BD9574MWF support

2020-12-15 Thread Yoshihiro Shimoda
Add support for BD9574MWF which is silimar chip with BD9571MWV.
Note that we don't support voltage rails VD{09,18,25,33} by this
driver on BD9574. The VD09 voltage could be read from PMIC but that
is not supported by this commit.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Matti Vaittinen 
---
 drivers/regulator/bd9571mwv-regulator.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/bd9571mwv-regulator.c 
b/drivers/regulator/bd9571mwv-regulator.c
index 42b6a70..7b0cd08 100644
--- a/drivers/regulator/bd9571mwv-regulator.c
+++ b/drivers/regulator/bd9571mwv-regulator.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * ROHM BD9571MWV-M regulator driver
+ * ROHM BD9571MWV-M and BD9574MWF-M regulator driver
  *
  * Copyright (C) 2017 Marek Vasut 
  *
@@ -9,6 +9,7 @@
  * NOTE: VD09 is missing
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -277,6 +278,7 @@ static int bd9571mwv_regulator_probe(struct platform_device 
*pdev)
struct regulator_dev *rdev;
unsigned int val;
int i;
+   enum rohm_chip_type chip = platform_get_device_id(pdev)->driver_data;
 
bdreg = devm_kzalloc(>dev, sizeof(*bdreg), GFP_KERNEL);
if (!bdreg)
@@ -292,6 +294,9 @@ static int bd9571mwv_regulator_probe(struct platform_device 
*pdev)
config.regmap = bdreg->regmap;
 
for (i = 0; i < ARRAY_SIZE(regulators); i++) {
+   /* BD9574MWF supports DVFS only */
+   if (chip == ROHM_CHIP_TYPE_BD9574 && regulators[i].id != DVFS)
+   continue;
rdev = devm_regulator_register(>dev, [i],
   );
if (IS_ERR(rdev)) {
@@ -339,7 +344,8 @@ static int bd9571mwv_regulator_probe(struct platform_device 
*pdev)
 }
 
 static const struct platform_device_id bd9571mwv_regulator_id_table[] = {
-   { "bd9571mwv-regulator", },
+   { "bd9571mwv-regulator", ROHM_CHIP_TYPE_BD9571 },
+   { "bd9574mwf-regulator", ROHM_CHIP_TYPE_BD9574 },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(platform, bd9571mwv_regulator_id_table);
-- 
2.7.4



[PATCH v3 03/12] mfd: rohm-generic: Add BD9571 and BD9574

2020-12-15 Thread Yoshihiro Shimoda
Add chip IDs for BD9571MWV and BD9574MWF.

Signed-off-by: Yoshihiro Shimoda 
Reviewed-by: Matti Vaittinen 
---
 include/linux/mfd/rohm-generic.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mfd/rohm-generic.h b/include/linux/mfd/rohm-generic.h
index 4283b5b..affacf8 100644
--- a/include/linux/mfd/rohm-generic.h
+++ b/include/linux/mfd/rohm-generic.h
@@ -12,6 +12,8 @@ enum rohm_chip_type {
ROHM_CHIP_TYPE_BD71847,
ROHM_CHIP_TYPE_BD70528,
ROHM_CHIP_TYPE_BD71828,
+   ROHM_CHIP_TYPE_BD9571,
+   ROHM_CHIP_TYPE_BD9574,
ROHM_CHIP_TYPE_AMOUNT
 };
 
-- 
2.7.4



[PATCH v3 01/12] mfd: bd9571mwv: Use devm_mfd_add_devices()

2020-12-15 Thread Yoshihiro Shimoda
To remove mfd devices when unload this driver, should use
devm_mfd_add_devices() instead.

Fixes: d3ea21272094 ("mfd: Add ROHM BD9571MWV-M MFD PMIC driver")
Signed-off-by: Yoshihiro Shimoda 
---
 drivers/mfd/bd9571mwv.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/mfd/bd9571mwv.c b/drivers/mfd/bd9571mwv.c
index fab3cdc..19d57a4 100644
--- a/drivers/mfd/bd9571mwv.c
+++ b/drivers/mfd/bd9571mwv.c
@@ -185,9 +185,9 @@ static int bd9571mwv_probe(struct i2c_client *client,
return ret;
}
 
-   ret = mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO, bd9571mwv_cells,
- ARRAY_SIZE(bd9571mwv_cells), NULL, 0,
- regmap_irq_get_domain(bd->irq_data));
+   ret = devm_mfd_add_devices(bd->dev, PLATFORM_DEVID_AUTO,
+  bd9571mwv_cells, ARRAY_SIZE(bd9571mwv_cells),
+  NULL, 0, 
regmap_irq_get_domain(bd->irq_data));
if (ret) {
regmap_del_irq_chip(bd->irq, bd->irq_data);
return ret;
-- 
2.7.4



[PATCH v3 00/12] treewide: bd9571mwv: Add support for BD9574MWF

2020-12-15 Thread Yoshihiro Shimoda
Add BD9574MWF support into bd9571mwv gpio, mfd and regulator drivers.
Latest Ebisu-4D boards has this chip instead of BD9571MWV so that
we need this patch series to detect this chip at runtime.

Note that the patch [1/12] is a bug-fix patch for mfd driver.

Changes from v2:
 - Use devm_mfd_add_devices() to remove the mfd device in unload.
 - Update commit descriptions in patch 4 and 8.
 - Use regmap_get_device() to simplify in patch 4.
 - Remove "struct bd9571mwv" and bd9571mwv_remove().
 - Add Reviewed-by in patch 3 to 9.
 - Use devm_regmap_add_irq_chip() to simplify in patch 10.
 https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=400477

Changes from v1:
 - Document BD9574MWF on the dt-binding.
 - Add ROHM_CHIP_TYPE_BD957[14] into rohm-generic.h.
 - To simplify gpio and regulator drivers, using regmap instead of
   using struct bd9571mwv.
 - Remove BD9574MWF definitions to make gpio and regulator driver
   simple to support for BD9574MWF.
 - Add BD9574MWF support for gpio and regulator drivers.
 - Add missing regmap ranges for BD9574MWF.
 - Rename "part_number" with "part_name".
 https://patchwork.kernel.org/project/linux-renesas-soc/list/?series=398059

Khiem Nguyen (2):
  mfd: bd9571mwv: Make the driver more generic
  mfd: bd9571mwv: Add support for BD9574MWF

Yoshihiro Shimoda (10):
  mfd: bd9571mwv: Use devm_mfd_add_devices()
  dt-bindings: mfd: bd9571mwv: Document BD9574MWF
  mfd: rohm-generic: Add BD9571 and BD9574
  regulator: bd9571mwv: rid of using struct bd9571mwv
  regulator: bd9571mwv: Add BD9574MWF support
  gpio: bd9571mwv: Use the SPDX license identifier
  gpio: bd9571mwv: rid of using struct bd9571mwv
  gpio: bd9571mwv: Add BD9574MWF support
  mfd: bd9571mwv: Use the SPDX license identifier
  mfd: bd9571mwv: Use devm_regmap_add_irq_chip()

 .../devicetree/bindings/mfd/bd9571mwv.txt  |   4 +-
 drivers/gpio/gpio-bd9571mwv.c  |  35 ++--
 drivers/mfd/bd9571mwv.c| 206 +++--
 drivers/regulator/bd9571mwv-regulator.c|  59 +++---
 include/linux/mfd/bd9571mwv.h  |  46 ++---
 include/linux/mfd/rohm-generic.h   |   2 +
 6 files changed, 216 insertions(+), 136 deletions(-)

-- 
2.7.4



Re: [PATCH] mm/memcontrol: remove the unnecessary rcu_read_[un]lock

2020-12-15 Thread Michal Hocko
On Wed 16-12-20 13:52:13, Hui Su wrote:
> the rcu_read_lock and rcu_read_unlock is unnecessary in:
>   lock_page_lruvec()
>   lock_page_lruvec_irq()
>   lock_page_lruvec_irqsave()

Please add an explanation why it is unnecessary.

> Signed-off-by: Hui Su 
> ---
>  mm/memcontrol.c | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index e3c7ca7dc174..a19f820e8a3f 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -1396,10 +1396,8 @@ struct lruvec *lock_page_lruvec(struct page *page)
>   struct lruvec *lruvec;
>   struct pglist_data *pgdat = page_pgdat(page);
>  
> - rcu_read_lock();
>   lruvec = mem_cgroup_page_lruvec(page, pgdat);
>   spin_lock(>lru_lock);
> - rcu_read_unlock();
>  
>   lruvec_memcg_debug(lruvec, page);
>  
> @@ -1411,10 +1409,8 @@ struct lruvec *lock_page_lruvec_irq(struct page *page)
>   struct lruvec *lruvec;
>   struct pglist_data *pgdat = page_pgdat(page);
>  
> - rcu_read_lock();
>   lruvec = mem_cgroup_page_lruvec(page, pgdat);
>   spin_lock_irq(>lru_lock);
> - rcu_read_unlock();
>  
>   lruvec_memcg_debug(lruvec, page);
>  
> @@ -1426,10 +1422,8 @@ struct lruvec *lock_page_lruvec_irqsave(struct page 
> *page, unsigned long *flags)
>   struct lruvec *lruvec;
>   struct pglist_data *pgdat = page_pgdat(page);
>  
> - rcu_read_lock();
>   lruvec = mem_cgroup_page_lruvec(page, pgdat);
>   spin_lock_irqsave(>lru_lock, *flags);
> - rcu_read_unlock();
>  
>   lruvec_memcg_debug(lruvec, page);
>  
> -- 
> 2.29.2

-- 
Michal Hocko
SUSE Labs


Re: [Bug 210655] ptrace.2: documentation is incorrect about access checking threads in same thread group

2020-12-15 Thread Oleg Nesterov
On 12/15, Linus Torvalds wrote:
>
> On Tue, Dec 15, 2020 at 2:48 PM Alejandro Colomar (man-pages)
>  wrote:
> >
> > 1) Remove that paragraph, as if that behavior had never existed.
> 
> If it's been 15 years since that paragraph was relevant, I think just
> removing it is the right thing to do.

Agreed.

Oleg.



Re: [PATCH v5 0/2] MTE support for KVM guest

2020-12-15 Thread Haibo Xu
On Mon, 7 Dec 2020 at 22:48, Steven Price  wrote:
>
> On 04/12/2020 08:25, Haibo Xu wrote:
> > On Fri, 20 Nov 2020 at 17:51, Steven Price  wrote:
> >>
> >> On 19/11/2020 19:11, Marc Zyngier wrote:
> >>> On 2020-11-19 18:42, Andrew Jones wrote:
>  On Thu, Nov 19, 2020 at 03:45:40PM +, Peter Maydell wrote:
> > On Thu, 19 Nov 2020 at 15:39, Steven Price  wrote:
> >> This series adds support for Arm's Memory Tagging Extension (MTE) to
> >> KVM, allowing KVM guests to make use of it. This builds on the
> > existing
> >> user space support already in v5.10-rc1, see [1] for an overview.
> >
> >> The change to require the VMM to map all guest memory PROT_MTE is
> >> significant as it means that the VMM has to deal with the MTE tags
> > even
> >> if it doesn't care about them (e.g. for virtual devices or if the VMM
> >> doesn't support migration). Also unfortunately because the VMM can
> >> change the memory layout at any time the check for PROT_MTE/VM_MTE has
> >> to be done very late (at the point of faulting pages into stage 2).
> >
> > I'm a bit dubious about requring the VMM to map the guest memory
> > PROT_MTE unless somebody's done at least a sketch of the design
> > for how this would work on the QEMU side. Currently QEMU just
> > assumes the guest memory is guest memory and it can access it
> > without special precautions...
> >
> 
>  There are two statements being made here:
> 
>  1) Requiring the use of PROT_MTE when mapping guest memory may not fit
>  QEMU well.
> 
>  2) New KVM features should be accompanied with supporting QEMU code in
>  order to prove that the APIs make sense.
> 
>  I strongly agree with (2). While kvmtool supports some quick testing, it
>  doesn't support migration. We must test all new features with a migration
>  supporting VMM.
> 
>  I'm not sure about (1). I don't feel like it should be a major problem,
>  but (2).
> >>
> >> (1) seems to be contentious whichever way we go. Either PROT_MTE isn't
> >> required in which case it's easy to accidentally screw up migration, or
> >> it is required in which case it's difficult to handle normal guest
> >> memory from the VMM. I get the impression that probably I should go back
> >> to the previous approach - sorry for the distraction with this change.
> >>
> >> (2) isn't something I'm trying to skip, but I'm limited in what I can do
> >> myself so would appreciate help here. Haibo is looking into this.
> >>
> >
> > Hi Steven,
> >
> > Sorry for the later reply!
> >
> > I have finished the POC for the MTE migration support with the assumption
> > that all the memory is mapped with PROT_MTE. But I got stuck in the test
> > with a FVP setup. Previously, I successfully compiled a test case to verify
> > the basic function of MTE in a guest. But these days, the re-compiled test
> > can't be executed by the guest(very weird). The short plan to verify
> > the migration
> > is to set the MTE tags on one page in the guest, and try to dump the 
> > migrated
> > memory contents.
>
> Hi Haibo,
>
> Sounds like you are making good progress - thanks for the update. Have
> you thought about how the PROT_MTE mappings might work if QEMU itself
> were to use MTE? My worry is that we end up with MTE in a guest
> preventing QEMU from using MTE itself (because of the PROT_MTE
> mappings). I'm hoping QEMU can wrap its use of guest memory in a
> sequence which disables tag checking (something similar will be needed
> for the "protected VM" use case anyway), but this isn't something I've
> looked into.
>
> > I will update the status later next week!
>
> Great, I look forward to hearing how it goes.

Hi Steve,

I have finished verifying the POC on a FVP setup, and the MTE test case can
be migrated from one VM to another successfully. Since the test case is very
simple which just maps one page with MTE enabled and does some memory
access, so I can't say it's OK for other cases.

BTW, I noticed that you have sent out patch set v6 which mentions that mapping
all the guest memory with PROT_MTE was not feasible. So what's the plan for the
next step? Will new KVM APIs which can facilitate the tag store and recover be
available?

Regards,
Haibo

>
> Thanks,
>
> Steve


[PATCH] mm, tracing: record slab name for kmem_cache_free()

2020-12-15 Thread Jacob Wen
Currently, a trace record generated by the RCU core is as below.

... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=f3b49a66

It doesn't tell us what the RCU core has freed.

This patch adds the slab name to trace_kmem_cache_free().
The new format is as follows.

... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=37f79c8d 
name=dentry
... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=f78cb7b5 
name=sock_inode_cache
... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=18768985 
name=pool_workqueue
... kmem_cache_free: call_site=rcu_core+0x1fd/0x610 ptr=6a6cb484 
name=radix_tree_node

We can use it to understand what the RCU core is going to free. For
example, some users maybe interested in when the RCU core starts
freeing reclaimable slabs like dentry to reduce memory pressure.

Signed-off-by: Jacob Wen 
---
 include/trace/events/kmem.h | 24 
 mm/slab.c   |  2 +-
 mm/slob.c   |  2 +-
 mm/slub.c   |  2 +-
 4 files changed, 19 insertions(+), 11 deletions(-)

diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index f65b1f6db22d..40845b0d5dad 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -115,7 +115,7 @@ DEFINE_EVENT(kmem_alloc_node, kmem_cache_alloc_node,
TP_ARGS(call_site, ptr, bytes_req, bytes_alloc, gfp_flags, node)
 );
 
-DECLARE_EVENT_CLASS(kmem_free,
+TRACE_EVENT(kfree,
 
TP_PROTO(unsigned long call_site, const void *ptr),
 
@@ -135,18 +135,26 @@ DECLARE_EVENT_CLASS(kmem_free,
  (void *)__entry->call_site, __entry->ptr)
 );
 
-DEFINE_EVENT(kmem_free, kfree,
+TRACE_EVENT(kmem_cache_free,
 
-   TP_PROTO(unsigned long call_site, const void *ptr),
+   TP_PROTO(unsigned long call_site, const void *ptr, const char *name),
 
-   TP_ARGS(call_site, ptr)
-);
+   TP_ARGS(call_site, ptr, name),
 
-DEFINE_EVENT(kmem_free, kmem_cache_free,
+   TP_STRUCT__entry(
+   __field(unsigned long,  call_site   )
+   __field(const void *,   ptr )
+   __field(const char *,   name)
+   ),
 
-   TP_PROTO(unsigned long call_site, const void *ptr),
+   TP_fast_assign(
+   __entry->call_site  = call_site;
+   __entry->ptr= ptr;
+   __entry->name   = name;
+   ),
 
-   TP_ARGS(call_site, ptr)
+   TP_printk("call_site=%pS ptr=%p name=%s",
+ (void *)__entry->call_site, __entry->ptr, __entry->name)
 );
 
 TRACE_EVENT(mm_page_free,
diff --git a/mm/slab.c b/mm/slab.c
index d7c8da9319c7..f35d395794bd 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -3697,7 +3697,7 @@ void kmem_cache_free(struct kmem_cache *cachep, void 
*objp)
__cache_free(cachep, objp, _RET_IP_);
local_irq_restore(flags);
 
-   trace_kmem_cache_free(_RET_IP_, objp);
+   trace_kmem_cache_free(_RET_IP_, objp, cachep->name);
 }
 EXPORT_SYMBOL(kmem_cache_free);
 
diff --git a/mm/slob.c b/mm/slob.c
index 8d4bfa46247f..ffb34600b48c 100644
--- a/mm/slob.c
+++ b/mm/slob.c
@@ -667,7 +667,7 @@ void kmem_cache_free(struct kmem_cache *c, void *b)
__kmem_cache_free(b, c->size);
}
 
-   trace_kmem_cache_free(_RET_IP_, b);
+   trace_kmem_cache_free(_RET_IP_, b, c->name);
 }
 EXPORT_SYMBOL(kmem_cache_free);
 
diff --git a/mm/slub.c b/mm/slub.c
index 4552319148f6..5c28d8721430 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3154,7 +3154,7 @@ void kmem_cache_free(struct kmem_cache *s, void *x)
if (!s)
return;
slab_free(s, virt_to_head_page(x), x, NULL, 1, _RET_IP_);
-   trace_kmem_cache_free(_RET_IP_, x);
+   trace_kmem_cache_free(_RET_IP_, x, s->name);
 }
 EXPORT_SYMBOL(kmem_cache_free);
 
-- 
2.17.1



[kbuild] Re: [PATCH 1/7] vfio: iommu_type1: Clear added dirty bit when unwind pin

2020-12-15 Thread Dan Carpenter
Hi Keqian,

url:
https://github.com/0day-ci/linux/commits/Keqian-Zhu/vfio-iommu_type1-Some-fixes-and-optimization/20201210-154322
 
base:   https://github.com/awilliam/linux-vfio.git  next
config: x86_64-randconfig-m001-20201215 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
drivers/vfio/vfio_iommu_type1.c:648 vfio_iommu_type1_pin_pages() warn: variable 
dereferenced before check 'iommu' (see line 640)

vim +/iommu +648 drivers/vfio/vfio_iommu_type1.c

a54eb55045ae9b3 Kirti Wankhede  2016-11-17  631  static int 
vfio_iommu_type1_pin_pages(void *iommu_data,
95fc87b44104d9a Kirti Wankhede  2020-05-29  632 
  struct iommu_group *iommu_group,
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  633 
  unsigned long *user_pfn,
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  634 
  int npage, int prot,
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  635 
  unsigned long *phys_pfn)
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  636  {
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  637 struct vfio_iommu 
*iommu = iommu_data;
95fc87b44104d9a Kirti Wankhede  2020-05-29  638 struct vfio_group 
*group;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  639 int i, j, ret;
2b172c0ea2a6daf Keqian Zhu  2020-12-10 @640 unsigned long pgshift = 
__ffs(iommu->pgsize_bitmap);

  
The patch introduces a new dereference.

a54eb55045ae9b3 Kirti Wankhede  2016-11-17  641 unsigned long 
remote_vaddr;
2b172c0ea2a6daf Keqian Zhu  2020-12-10  642 unsigned long 
bitmap_offset;
2b172c0ea2a6daf Keqian Zhu  2020-12-10  643 unsigned long 
*bitmap_added;
2b172c0ea2a6daf Keqian Zhu  2020-12-10  644 dma_addr_t iova;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  645 struct vfio_dma *dma;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  646 bool do_accounting;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  647  
a54eb55045ae9b3 Kirti Wankhede  2016-11-17 @648 if (!iommu || !user_pfn 
|| !phys_pfn)
^^
Checked too late.

a54eb55045ae9b3 Kirti Wankhede  2016-11-17  649 return -EINVAL;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  650  
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  651 /* Supported for v2 
version only */
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  652 if (!iommu->v2)
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  653 return -EACCES;
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  654  
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  655 
mutex_lock(>lock);
a54eb55045ae9b3 Kirti Wankhede  2016-11-17  656  

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


.config.gz
Description: application/gzip
___
kbuild mailing list -- kbu...@lists.01.org
To unsubscribe send an email to kbuild-le...@lists.01.org


Re: [kbuild-all] Re: drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn

2020-12-15 Thread Rong Chen




On 12/15/20 11:40 PM, Willy Tarreau wrote:

Hi,

On Tue, Dec 15, 2020 at 11:05:28PM +0800, kernel test robot wrote:

Hi Willy,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   148842c98a24e508aecb929718818fbf4c2a6ff3
commit: 3744741adab6d9195551ce30e65e726c7a408421 random32: add noise from 
network and scheduling activity

(...)

not sure why I'm assigned this, but the root cause is a compiler bug:

drivers/mtd/tests/subpagetest.c: In function 'mtd_subpagetest_init':

drivers/mtd/tests/subpagetest.c:426:1: error: could not split insn

  426 | }
  | ^
(insn:TI 453 2652 455 (set (reg/v:SI 3 a3 [orig:304 a ] [304])
(xor:SI (reg:SI 1 a1 [orig:717 net_rand_noise ] [717])
(const:SI (plus:SI (symbol_ref:SI ("*.LANCHOR0") [flags 0x182])
(const_int 12 [0xc]) "include/linux/prandom.h":66:4 
152 {cskyv2_xorsi3}
 (expr_list:REG_DEAD (reg:SI 1 a1 [orig:717 net_rand_noise ] [717])
(nil)))
during RTL pass: final
drivers/mtd/tests/subpagetest.c:426:1: internal compiler error: in 
final_scan_insn_1, at final.c:3074

 ^^^


0x510da0 _fatal_insn(char const*, rtx_def const*, char const*, int, char 
const*)
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/rtl-error.c:108
0x503d22 final_scan_insn_1
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:3074
0x73f8bf final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:3153
0x73fbac final_1
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:2021
0x740618 rest_of_handle_final
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:4659
0x740618 execute
/tmp/build-crosstools-xh-9.3.0-2.34/gcc/gcc-9.3.0/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

   ^

That's totally out of my scope. I suspect it might have broken a bisect
operation.


Hi Willy,

Thanks for the feedback, I have created a issue in GCC Bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98310

Best Regards,
Rong Chen



Regards,
Willy
___
kbuild-all mailing list -- kbuild-...@lists.01.org
To unsubscribe send an email to kbuild-all-le...@lists.01.org




[PATCH] soc: qcom: socinfo: Open read access to all for debugfs

2020-12-15 Thread Stephen Boyd
There doesn't seem to be any reason to limit this to only root user
readable. Let's make it readable by all so that random programs can
read the debugfs files in here instead of just root. The information is
just that, informational, so this is fine.

Cc: Sai Prakash Ranjan 
Cc: Douglas Anderson 
Cc: Dmitry Baryshkov 
Signed-off-by: Stephen Boyd 
---
 drivers/soc/qcom/socinfo.c | 40 +++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/soc/qcom/socinfo.c b/drivers/soc/qcom/socinfo.c
index b44ede48decc..4e4946d9e4ab 100644
--- a/drivers/soc/qcom/socinfo.c
+++ b/drivers/soc/qcom/socinfo.c
@@ -258,7 +258,7 @@ static const struct file_operations qcom_ ##name## _ops = { 
\
 }
 
 #define DEBUGFS_ADD(info, name)
\
-   debugfs_create_file(__stringify(name), 0400,\
+   debugfs_create_file(__stringify(name), 0444,\
qcom_socinfo->dbg_root, \
info, _ ##name## _ops)
 
@@ -349,14 +349,14 @@ static void socinfo_debugfs_init(struct qcom_socinfo 
*qcom_socinfo,
 
qcom_socinfo->info.fmt = __le32_to_cpu(info->fmt);
 
-   debugfs_create_x32("info_fmt", 0400, qcom_socinfo->dbg_root,
+   debugfs_create_x32("info_fmt", 0444, qcom_socinfo->dbg_root,
   _socinfo->info.fmt);
 
switch (qcom_socinfo->info.fmt) {
case SOCINFO_VERSION(0, 15):
qcom_socinfo->info.nmodem_supported = 
__le32_to_cpu(info->nmodem_supported);
 
-   debugfs_create_u32("nmodem_supported", 0400, 
qcom_socinfo->dbg_root,
+   debugfs_create_u32("nmodem_supported", 0444, 
qcom_socinfo->dbg_root,
   _socinfo->info.nmodem_supported);
fallthrough;
case SOCINFO_VERSION(0, 14):
@@ -365,19 +365,19 @@ static void socinfo_debugfs_init(struct qcom_socinfo 
*qcom_socinfo,
qcom_socinfo->info.num_defective_parts = 
__le32_to_cpu(info->num_defective_parts);
qcom_socinfo->info.ndefective_parts_array_offset = 
__le32_to_cpu(info->ndefective_parts_array_offset);
 
-   debugfs_create_u32("num_clusters", 0400, qcom_socinfo->dbg_root,
+   debugfs_create_u32("num_clusters", 0444, qcom_socinfo->dbg_root,
   _socinfo->info.num_clusters);
-   debugfs_create_u32("ncluster_array_offset", 0400, 
qcom_socinfo->dbg_root,
+   debugfs_create_u32("ncluster_array_offset", 0444, 
qcom_socinfo->dbg_root,
   _socinfo->info.ncluster_array_offset);
-   debugfs_create_u32("num_defective_parts", 0400, 
qcom_socinfo->dbg_root,
+   debugfs_create_u32("num_defective_parts", 0444, 
qcom_socinfo->dbg_root,
   _socinfo->info.num_defective_parts);
-   debugfs_create_u32("ndefective_parts_array_offset", 0400, 
qcom_socinfo->dbg_root,
+   debugfs_create_u32("ndefective_parts_array_offset", 0444, 
qcom_socinfo->dbg_root,
   
_socinfo->info.ndefective_parts_array_offset);
fallthrough;
case SOCINFO_VERSION(0, 13):
qcom_socinfo->info.nproduct_id = 
__le32_to_cpu(info->nproduct_id);
 
-   debugfs_create_u32("nproduct_id", 0400, qcom_socinfo->dbg_root,
+   debugfs_create_u32("nproduct_id", 0444, qcom_socinfo->dbg_root,
   _socinfo->info.nproduct_id);
DEBUGFS_ADD(info, chip_id);
fallthrough;
@@ -389,12 +389,12 @@ static void socinfo_debugfs_init(struct qcom_socinfo 
*qcom_socinfo,
qcom_socinfo->info.raw_device_num =
__le32_to_cpu(info->raw_device_num);
 
-   debugfs_create_x32("chip_family", 0400, qcom_socinfo->dbg_root,
+   debugfs_create_x32("chip_family", 0444, qcom_socinfo->dbg_root,
   _socinfo->info.chip_family);
-   debugfs_create_x32("raw_device_family", 0400,
+   debugfs_create_x32("raw_device_family", 0444,
   qcom_socinfo->dbg_root,
   _socinfo->info.raw_device_family);
-   debugfs_create_x32("raw_device_number", 0400,
+   debugfs_create_x32("raw_device_number", 0444,
   qcom_socinfo->dbg_root,
   _socinfo->info.raw_device_num);
fallthrough;
@@ -403,7 +403,7 @@ static void socinfo_debugfs_init(struct qcom_socinfo 
*qcom_socinfo,
case SOCINFO_VERSION(0, 9):
qcom_socinfo->info.foundry_id = __le32_to_cpu(info->foundry_id);
 
-   debugfs_create_u32("foundry_id", 0400, qcom_socinfo->dbg_root,
+   

Re: [PATCH bpf-next v4 10/11] bpf: Add tests for new BPF atomic operations

2020-12-15 Thread Yonghong Song




On 12/15/20 3:12 AM, Brendan Jackman wrote:

On Tue, Dec 08, 2020 at 10:15:35AM -0800, Yonghong Song wrote:



On 12/8/20 8:59 AM, Brendan Jackman wrote:

On Tue, Dec 08, 2020 at 08:38:04AM -0800, Yonghong Song wrote:



On 12/8/20 4:41 AM, Brendan Jackman wrote:

On Mon, Dec 07, 2020 at 07:18:57PM -0800, Yonghong Song wrote:



On 12/7/20 8:07 AM, Brendan Jackman wrote:

The prog_test that's added depends on Clang/LLVM features added by
Yonghong in commit 286daafd6512 (was https://reviews.llvm.org/D72184).

Note the use of a define called ENABLE_ATOMICS_TESTS: this is used
to:

 - Avoid breaking the build for people on old versions of Clang
 - Avoid needing separate lists of test objects for no_alu32, where
   atomics are not supported even if Clang has the feature.

The atomics_test.o BPF object is built unconditionally both for
test_progs and test_progs-no_alu32. For test_progs, if Clang supports
atomics, ENABLE_ATOMICS_TESTS is defined, so it includes the proper
test code. Otherwise, progs and global vars are defined anyway, as
stubs; this means that the skeleton user code still builds.

The atomics_test.o userspace object is built once and used for both
test_progs and test_progs-no_alu32. A variable called skip_tests is
defined in the BPF object's data section, which tells the userspace
object whether to skip the atomics test.

Signed-off-by: Brendan Jackman 


Ack with minor comments below.

Acked-by: Yonghong Song 


---
 tools/testing/selftests/bpf/Makefile  |  10 +
 .../selftests/bpf/prog_tests/atomics.c| 246 ++
 tools/testing/selftests/bpf/progs/atomics.c   | 154 +++
 .../selftests/bpf/verifier/atomic_and.c   |  77 ++
 .../selftests/bpf/verifier/atomic_cmpxchg.c   |  96 +++
 .../selftests/bpf/verifier/atomic_fetch_add.c | 106 
 .../selftests/bpf/verifier/atomic_or.c|  77 ++
 .../selftests/bpf/verifier/atomic_xchg.c  |  46 
 .../selftests/bpf/verifier/atomic_xor.c   |  77 ++
 9 files changed, 889 insertions(+)
 create mode 100644 tools/testing/selftests/bpf/prog_tests/atomics.c
 create mode 100644 tools/testing/selftests/bpf/progs/atomics.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_and.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_cmpxchg.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_fetch_add.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_or.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_xchg.c
 create mode 100644 tools/testing/selftests/bpf/verifier/atomic_xor.c

diff --git a/tools/testing/selftests/bpf/Makefile 
b/tools/testing/selftests/bpf/Makefile
index ac25ba5d0d6c..13bc1d736164 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -239,6 +239,12 @@ BPF_CFLAGS = -g -D__TARGET_ARCH_$(SRCARCH) $(MENDIAN)  
\
 -I$(INCLUDE_DIR) -I$(CURDIR) -I$(APIDIR)   \
 -I$(abspath $(OUTPUT)/../usr/include)
+# BPF atomics support was added to Clang in llvm-project commit 286daafd6512
+# (release 12.0.0).
+BPF_ATOMICS_SUPPORTED = $(shell \
+   echo "int x = 0; int foo(void) { return __sync_val_compare_and_swap(, 1, 
2); }" \
+   | $(CLANG) -x cpp-output -S -target bpf -mcpu=v3 - -o /dev/null && echo 
1 || echo 0)


'-x c' here more intuitive?


+
 CLANG_CFLAGS = $(CLANG_SYS_INCLUDES) \
   -Wno-compare-distinct-pointer-types
@@ -399,11 +405,15 @@ TRUNNER_EXTRA_FILES := $(OUTPUT)/urandom_read 
$(OUTPUT)/bpf_testmod.ko\
   $(wildcard progs/btf_dump_test_case_*.c)
 TRUNNER_BPF_BUILD_RULE := CLANG_BPF_BUILD_RULE
 TRUNNER_BPF_CFLAGS := $(BPF_CFLAGS) $(CLANG_CFLAGS)
+ifeq ($(BPF_ATOMICS_SUPPORTED),1)
+  TRUNNER_BPF_CFLAGS += -DENABLE_ATOMICS_TESTS
+endif
 TRUNNER_BPF_LDFLAGS := -mattr=+alu32
 $(eval $(call DEFINE_TEST_RUNNER,test_progs))
 # Define test_progs-no_alu32 test runner.
 TRUNNER_BPF_BUILD_RULE := CLANG_NOALU32_BPF_BUILD_RULE
+TRUNNER_BPF_CFLAGS := $(BPF_CFLAGS) $(CLANG_CFLAGS)
 TRUNNER_BPF_LDFLAGS :=
 $(eval $(call DEFINE_TEST_RUNNER,test_progs,no_alu32))
diff --git a/tools/testing/selftests/bpf/prog_tests/atomics.c 
b/tools/testing/selftests/bpf/prog_tests/atomics.c
new file mode 100644
index ..c841a3abc2f7
--- /dev/null
+++ b/tools/testing/selftests/bpf/prog_tests/atomics.c
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+
+#include "atomics.skel.h"
+
+static void test_add(struct atomics *skel)
+{
+   int err, prog_fd;
+   __u32 duration = 0, retval;
+   struct bpf_link *link;
+
+   link = bpf_program__attach(skel->progs.add);
+   if (CHECK(IS_ERR(link), "attach(add)", "err: %ld\n", PTR_ERR(link)))
+   return;
+
+   prog_fd = bpf_program__fd(skel->progs.add);
+   err = 

Re: KASAN: use-after-free Write in __sco_sock_close

2020-12-15 Thread syzbot
syzbot suspects this issue was fixed by commit:

commit 6dfccd13db2ff2b709ef60a50163925d477549aa
Author: Anmol Karn 
Date:   Wed Sep 30 14:18:13 2020 +

Bluetooth: Fix null pointer dereference in hci_event_packet()

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=14cb845b50
start commit:   47ec5303 Merge git://git.kernel.org/pub/scm/linux/kernel/g..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=e0c783f658542f35
dashboard link: https://syzkaller.appspot.com/bug?extid=077eca30d3cb7c02b273
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=165a89dc90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=130a8c6290

If the result looks correct, please mark the issue as fixed by replying with:

#syz fix: Bluetooth: Fix null pointer dereference in hci_event_packet()

For information about bisection process see: https://goo.gl/tpsmEJ#bisection


Re: [PATCH bpf-next v5 11/11] bpf: Document new atomic instructions

2020-12-15 Thread Yonghong Song




On 12/15/20 4:18 AM, Brendan Jackman wrote:

Document new atomic instructions.

Signed-off-by: Brendan Jackman 


Ack with minor comments below.

Acked-by: Yonghong Song 


---
  Documentation/networking/filter.rst | 26 ++
  1 file changed, 26 insertions(+)

diff --git a/Documentation/networking/filter.rst 
b/Documentation/networking/filter.rst
index 1583d59d806d..26d508a5e038 100644
--- a/Documentation/networking/filter.rst
+++ b/Documentation/networking/filter.rst
@@ -1053,6 +1053,32 @@ encoding.
 .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W  | BPF_STX: lock xadd *(u32 
*)(dst_reg + off16) += src_reg
 .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 
*)(dst_reg + off16) += src_reg
  
+The basic atomic operations supported (from architecture v4 onwards) are:


Remove "(from architecture v4 onwards)".


+
+BPF_ADD
+BPF_AND
+BPF_OR
+BPF_XOR
+
+Each having equivalent semantics with the ``BPF_ADD`` example, that is: the
+memory location addresed by ``dst_reg + off`` is atomically modified, with
+``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the
+immediate, then these operations also overwrite ``src_reg`` with the
+value that was in memory before it was modified.
+
+The more special operations are:
+
+BPF_XCHG
+
+This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg +
+off``.
+
+BPF_CMPXCHG
+
+This atomically compares the value addressed by ``dst_reg + off`` with
+``R0``. If they match it is replaced with ``src_reg``, The value that was there
+before is loaded back to ``R0``.
+
  Note that 1 and 2 byte atomic operations are not supported.


Adding something like below.

Except xadd for legacy reason, all other 4 byte atomic operations 
require alu32 mode.
The alu32 mode can be enabled with clang flags "-Xclang -target-feature 
-Xclang +alu32" or "-mcpu=v3". The cpu version 3 has alu32 mode on by 
default.


  
  You may encounter BPF_XADD - this is a legacy name for BPF_ATOMIC, referring to




[PATCH] venus: venc: set IDR period to FW only for H264 & HEVC

2020-12-15 Thread Dikshita Agarwal
HFI_PROPERTY_CONFIG_VENC_IDR_PERIOD is supported for only
H264 & HEVC codec. There is no need to set it for VP8 since
all key frames are treated as IDR frames for VP8.

Signed-off-by: Dikshita Agarwal 
---
 drivers/media/platform/qcom/venus/venc.c | 23 +--
 1 file changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c 
b/drivers/media/platform/qcom/venus/venc.c
index 3a2e449..618cf92 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -588,16 +588,19 @@ static int venc_set_properties(struct venus_inst *inst)
return ret;
}
 
-   /* IDR periodicity, n:
-* n = 0 - only the first I-frame is IDR frame
-* n = 1 - all I-frames will be IDR frames
-* n > 1 - every n-th I-frame will be IDR frame
-*/
-   ptype = HFI_PROPERTY_CONFIG_VENC_IDR_PERIOD;
-   idrp.idr_period = 0;
-   ret = hfi_session_set_property(inst, ptype, );
-   if (ret)
-   return ret;
+   if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+   inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+   /* IDR periodicity, n:
+* n = 0 - only the first I-frame is IDR frame
+* n = 1 - all I-frames will be IDR frames
+* n > 1 - every n-th I-frame will be IDR frame
+*/
+   ptype = HFI_PROPERTY_CONFIG_VENC_IDR_PERIOD;
+   idrp.idr_period = 0;
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+   }
 
if (ctr->num_b_frames) {
u32 max_num_b_frames = NUM_B_FRAMES_MAX;
-- 
2.7.4



[PATCH net-next] net: rds: Change PF_INET to AF_INET

2020-12-15 Thread Zheng Yongjun
By bsd codestyle, change PF_INET to AF_INET.

Signed-off-by: Zheng Yongjun 
---
 net/rds/rdma_transport.c | 4 ++--
 net/rds/tcp_listen.c | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/net/rds/rdma_transport.c b/net/rds/rdma_transport.c
index 5f741e51b4ba..04102dbc04d2 100644
--- a/net/rds/rdma_transport.c
+++ b/net/rds/rdma_transport.c
@@ -249,7 +249,7 @@ static int rds_rdma_listen_init(void)
 #endif
struct sockaddr_in sin;
 
-   sin.sin_family = PF_INET;
+   sin.sin_family = AF_INET;
sin.sin_addr.s_addr = htonl(INADDR_ANY);
sin.sin_port = htons(RDS_PORT);
ret = rds_rdma_listen_init_common(rds_rdma_cm_event_handler,
@@ -259,7 +259,7 @@ static int rds_rdma_listen_init(void)
return ret;
 
 #if IS_ENABLED(CONFIG_IPV6)
-   sin6.sin6_family = PF_INET6;
+   sin6.sin6_family = AF_INET6;
sin6.sin6_addr = in6addr_any;
sin6.sin6_port = htons(RDS_CM_PORT);
sin6.sin6_scope_id = 0;
diff --git a/net/rds/tcp_listen.c b/net/rds/tcp_listen.c
index 101cf14215a0..8dc71aee4691 100644
--- a/net/rds/tcp_listen.c
+++ b/net/rds/tcp_listen.c
@@ -281,7 +281,7 @@ struct socket *rds_tcp_listen_init(struct net *net, bool 
isv6)
 
if (isv6) {
sin6 = (struct sockaddr_in6 *)
-   sin6->sin6_family = PF_INET6;
+   sin6->sin6_family = AF_INET6;
sin6->sin6_addr = in6addr_any;
sin6->sin6_port = (__force u16)htons(RDS_TCP_PORT);
sin6->sin6_scope_id = 0;
@@ -289,7 +289,7 @@ struct socket *rds_tcp_listen_init(struct net *net, bool 
isv6)
addr_len = sizeof(*sin6);
} else {
sin = (struct sockaddr_in *)
-   sin->sin_family = PF_INET;
+   sin->sin_family = AF_INET;
sin->sin_addr.s_addr = INADDR_ANY;
sin->sin_port = (__force u16)htons(RDS_TCP_PORT);
addr_len = sizeof(*sin);
-- 
2.22.0



[PATCH] perf stat: Fix wrong skipping for per-die aggregation

2020-12-15 Thread Jin Yao
Uncore becomes die-scope on Xeon Cascade Lake-AP and perf has supported
--per-die aggregation yet.

One issue is found in check_per_pkg() for uncore events running on
AP system. On cascade Lake-AP, we have:

S0-D0
S0-D1
S1-D0
S1-D1

But in check_per_pkg(), S0-D1 and S1-D1 are skipped because the
mask bits for S0 and S1 have been set for S0-D0 and S1-D0. It doesn't
check die_id. So the counting for S0-D1 and S1-D1 are set to zero.
That's not correct.

root@lkp-csl-2ap4 ~# ./perf stat -a -I 1000 -e llc_misses.mem_read --per-die -- 
sleep 5
 1.001460963 S0-D0   11317376 Bytes llc_misses.mem_read
 1.001460963 S0-D1   1 998016 Bytes llc_misses.mem_read
 1.001460963 S1-D0   1 970496 Bytes llc_misses.mem_read
 1.001460963 S1-D1   11291264 Bytes llc_misses.mem_read
 2.003488021 S0-D0   11082048 Bytes llc_misses.mem_read
 2.003488021 S0-D1   11919040 Bytes llc_misses.mem_read
 2.003488021 S1-D0   1 890752 Bytes llc_misses.mem_read
 2.003488021 S1-D1   12380800 Bytes llc_misses.mem_read
 3.005613270 S0-D0   11126080 Bytes llc_misses.mem_read
 3.005613270 S0-D1   12898176 Bytes llc_misses.mem_read
 3.005613270 S1-D0   1 870912 Bytes llc_misses.mem_read
 3.005613270 S1-D1   13388608 Bytes llc_misses.mem_read
 4.007627598 S0-D0   11124608 Bytes llc_misses.mem_read
 4.007627598 S0-D1   13884416 Bytes llc_misses.mem_read
 4.007627598 S1-D0   1 921088 Bytes llc_misses.mem_read
 4.007627598 S1-D1   14451840 Bytes llc_misses.mem_read
 5.001479927 S0-D0   1 963328 Bytes llc_misses.mem_read
 5.001479927 S0-D1   14831936 Bytes llc_misses.mem_read
 5.001479927 S1-D0   1 895104 Bytes llc_misses.mem_read
 5.001479927 S1-D1   15496640 Bytes llc_misses.mem_read

>From above output, we can see S0-D1 and S1-D1 don't report the interval
values, they are continued to grow. That's because check_per_pkg() wrongly
decides to use zero counts for S0-D1 and S1-D1.

So in check_per_pkg(), we should use a pair of die_id + socket_id to
decide if this cpu counts needs to skip. Only considering socket_id is
not enough.

Now with this patch,

root@lkp-csl-2ap4 ~# ./perf stat -a -I 1000 -e llc_misses.mem_read --per-die -- 
sleep 5
 1.001622560 S0-D0   11210176 Bytes llc_misses.mem_read
 1.001622560 S0-D1   1 950208 Bytes llc_misses.mem_read
 1.001622560 S1-D0   1 968704 Bytes llc_misses.mem_read
 1.001622560 S1-D1   11113280 Bytes llc_misses.mem_read
 2.004399430 S0-D0   11258560 Bytes llc_misses.mem_read
 2.004399430 S0-D1   11011008 Bytes llc_misses.mem_read
 2.004399430 S1-D0   11036544 Bytes llc_misses.mem_read
 2.004399430 S1-D1   11237376 Bytes llc_misses.mem_read
 3.006535657 S0-D0   11036608 Bytes llc_misses.mem_read
 3.006535657 S0-D1   1 906560 Bytes llc_misses.mem_read
 3.006535657 S1-D0   1 994112 Bytes llc_misses.mem_read
 3.006535657 S1-D1   11025472 Bytes llc_misses.mem_read
 4.008934402 S0-D0   11005120 Bytes llc_misses.mem_read
 4.008934402 S0-D1   1 882368 Bytes llc_misses.mem_read
 4.008934402 S1-D0   1 961408 Bytes llc_misses.mem_read
 4.008934402 S1-D1   1 988352 Bytes llc_misses.mem_read
 5.001605406 S0-D0   11930240 Bytes llc_misses.mem_read
 5.001605406 S0-D1   11134272 Bytes llc_misses.mem_read
 5.001605406 S1-D0   11531136 Bytes llc_misses.mem_read
 5.001605406 S1-D1   12230848 Bytes llc_misses.mem_read

On no-die system, die_id is 0, this patch keeps original behavior unchanged.

Reported-by: Huang Ying 
Signed-off-by: Jin Yao 
---
 tools/perf/util/cpumap.h |  2 ++
 tools/perf/util/stat.c   | 21 +
 2 files changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/cpumap.h b/tools/perf/util/cpumap.h
index 3a442f021468..58604c047121 100644
--- a/tools/perf/util/cpumap.h
+++ b/tools/perf/util/cpumap.h
@@ -7,6 +7,8 @@
 #include 
 #include 
 
+#define CPU_MAP_MAX_DIE256
+
 struct perf_record_cpu_map_data;
 
 struct perf_cpu_map *perf_cpu_map__empty_new(int nr);
diff --git a/tools/perf/util/stat.c b/tools/perf/util/stat.c
index 1e125e39ff84..b3fc6e261fe0 100644
--- a/tools/perf/util/stat.c
+++ b/tools/perf/util/stat.c
@@ -282,9 +282,9 @@ static 

Re: [PATCH] xen: remove trailing semicolon in macro definition

2020-12-15 Thread Jürgen Groß

On 27.11.20 17:07, t...@redhat.com wrote:

From: Tom Rix 

The macro use will already have a semicolon.

Signed-off-by: Tom Rix 


Applied to: xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 058/141] xen-blkfront: Fix fall-through warnings for Clang

2020-12-15 Thread Jürgen Groß

On 20.11.20 19:32, Gustavo A. R. Silva wrote:

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 


Applied to: xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 138/141] xen/manage: Fix fall-through warnings for Clang

2020-12-15 Thread Jürgen Groß

On 20.11.20 19:40, Gustavo A. R. Silva wrote:

In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning
by explicitly adding a break statement instead of letting the code fall
through to the next case.

Link: https://github.com/KSPP/linux/issues/115
Signed-off-by: Gustavo A. R. Silva 


Applied to: xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH 0/2] Remove Xen PVH dependency on PCI

2020-12-15 Thread Jürgen Groß

On 14.10.20 19:53, Jason Andryuk wrote:

A Xen PVH domain doesn't have a PCI bus or devices, so it doesn't need
PCI support built in.  Currently, XEN_PVH depends on XEN_PVHVM which
depends on PCI.

The first patch introduces XEN_PVHVM_GUEST as a toplevel item and
changes XEN_PVHVM to a hidden variable.  This allows XEN_PVH to depend
on XEN_PVHVM without PCI while XEN_PVHVM_GUEST depends on PCI.

The second patch moves XEN_512GB to clean up the option nesting.

Jason Andryuk (2):
   xen: Remove Xen PVH/PVHVM dependency on PCI
   xen: Kconfig: nest Xen guest options

  arch/x86/xen/Kconfig | 38 ++
  drivers/xen/Makefile |  2 +-
  2 files changed, 23 insertions(+), 17 deletions(-)



Series applied to: xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: [PATCH -next v2] x86/xen: Convert to DEFINE_SHOW_ATTRIBUTE

2020-12-15 Thread Jürgen Groß

On 17.09.20 14:55, Qinglang Miao wrote:

Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.

Signed-off-by: Qinglang Miao 


Applied to: xen/tip.git for-linus-5.11


Juergen


OpenPGP_0xB0DE9DD628BF132F.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


[PATCH] perf inject: correct event attribute sizes

2020-12-15 Thread Denis Nikitin
When perf inject reads a perf.data file from an older version of perf,
it writes event attributes into the output with the original size field,
but lays them out as if they had the size currently used. Readers see
a corrupt file. Update the size field to match the layout.

Signed-off-by: Al Grant 
Signed-off-by: Denis Nikitin 
---
 tools/perf/util/header.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index be850e9f8852..0d95981df8dd 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -3331,6 +3331,14 @@ int perf_session__write_header(struct perf_session 
*session,
attr_offset = lseek(ff.fd, 0, SEEK_CUR);
 
evlist__for_each_entry(evlist, evsel) {
+   if (evsel->core.attr.size < sizeof(evsel->core.attr)) {
+   /*
+* We are likely in "perf inject" and have read
+* from an older file. Update attr size so that
+* reader gets the right offset to the ids.
+*/
+   evsel->core.attr.size = sizeof(evsel->core.attr);
+   }
f_attr = (struct perf_file_attr){
.attr = evsel->core.attr,
.ids  = {
-- 
2.29.2.684.gfbc64c5ab5-goog



Re: [PATCH v2 03/10] regulator: bd9571mwv: rid of using struct bd9571mwv

2020-12-15 Thread Vaittinen, Matti

On Wed, 2020-12-16 at 06:29 +, Yoshihiro Shimoda wrote:
> Hi Matti-san,
> 
> > From: Vaittinen, Matti, Sent: Wednesday, December 16, 2020 3:00 PM
> > On Wed, 2020-12-16 at 02:13 +, Yoshihiro Shimoda wrote:
> > > Hi Geert-san, Matti-san,
> > > 
> > > > From: Geert Uytterhoeven, Sent: Wednesday, December 16, 2020
> > > > 1:13
> > > > AM
> > > > On Tue, Dec 15, 2020 at 5:02 PM Geert Uytterhoeven <
> > > > ge...@linux-m68k.org> wrote:
> > > > > On Fri, Dec 11, 2020 at 3:03 PM Vaittinen, Matti
> > > > >  wrote:
> > > > > > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > > 
> > > > > > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > > > > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > > > > > @@ -17,7 +17,7 @@
> > > > > > >  #include 
> > > > > > > 
> > > > > > >  struct bd9571mwv_reg {
> > > > > > > - struct bd9571mwv *bd;
> > > > > > > + struct regmap *regmap;
> > > > > > 
> > > > > > As a 'nit':
> > > > > > I might consider adding the dev pointer here to avoid extra
> > > > > > argument
> > > > > > with all the bkup_mode functions below. (just pass this
> > > > > > struct
> > > > > > and
> > > > > > mode). But that's only my preference - feel free to ignore
> > > > > > this
> > > > > > comment
> > > > > > if patch is Ok to Mark, Marek & Others :)
> > > > > 
> > > > > Struct regmap already contains a struct device pointer, but
> > > > > that's internal
> > > > > to regmap.
> > > > > 
> > > > > Perhaps adding a regmap_device() helper to retrieve the
> > > > > device
> > > > > pointer
> > > > > might be worthwhile?
> > > > 
> > > > -EEXISTS ;-)
> > > > 
> > > > struct device *regmap_get_device(struct regmap *map)
> > > 
> > > Thank you for finding this. I'll fix this patch.
> > 
> > Just a small reminder that this device is probably the MFD device,
> > not
> > the device created for regulator driver. (Regmap is created for
> > MFD).
> > For prints this only means we're issuing prints as if MFD device
> > generated them, right? I'm not sure it is the best approach - but
> > I'll
> > leave this to Mark & others to judge :)
> 
> Thank you for the comment. You're correct. regmap_get_device() is
> the MFD device. Also, original code had used the MFD device as
> "dev_err(bd->dev, ...)". So, printk behavior is the same as before :)

Right. I must admit didn't catch that. I actually think using the
>dev for prints issued by the regulator driver would be more
correct but I'm not complaining if using MFD device is Ok to Mark &
others :) I do appreciate your work with this, thanks!

> 
> Best regards,
> Yoshihiro Shimoda
> 



Re: [PATCH bpf-next v5 09/11] bpf: Add bitwise atomic instructions

2020-12-15 Thread Yonghong Song




On 12/15/20 4:18 AM, Brendan Jackman wrote:

This adds instructions for

atomic[64]_[fetch_]and
atomic[64]_[fetch_]or
atomic[64]_[fetch_]xor

All these operations are isomorphic enough to implement with the same
verifier, interpreter, and x86 JIT code, hence being a single commit.

The main interesting thing here is that x86 doesn't directly support
the fetch_ version these operations, so we need to generate a CMPXCHG
loop in the JIT. This requires the use of two temporary registers,
IIUC it's safe to use BPF_REG_AX and x86's AUX_REG for this purpose.

Signed-off-by: Brendan Jackman 


Acked-by: Yonghong Song 


[PATCH 21/21] vdpasim: control virtqueue support

2020-12-15 Thread Jason Wang
This patch introduces the control virtqueue support for vDPA
simulator. This is a requirement for supporting advanced features like
multiqueue.

A requirement for control virtqueue is to isolate its memory access
from the rx/tx virtqueues. This is because when using vDPA device
for VM, the control virqueue is not directly assigned to VM. Userspace
(Qemu) will present a shadow control virtqueue to control for
recording the device states.

The isolation is done via the virtqueue groups and ASID support in
vDPA through vhost-vdpa. The simulator is extended to have:

1) three virtqueues: RXVQ, TXVQ and CVQ (control virtqueue)
2) two virtqueue groups: group 0 contains RXVQ and TXVQ; group 1
   contains CVQ
3) two address spaces and the simulator simply implements the address
   spaces by mapping it 1:1 to IOTLB.

For the VM use cases, userspace(Qemu) may set AS 0 to group 0 and AS 1
to group 1. So we have:

1) The IOTLB for virtqueue group 0 contains the mappings of guest, so
   RX and TX can be assigned to guest directly.
2) The IOTLB for virtqueue group 1 contains the mappings of CVQ which
   is the buffers that allocated and managed by VMM only. So CVQ of
   vhost-vdpa is visible to VMM only. And Guest can not access the CVQ
   of vhost-vdpa.

For the other use cases, since AS 0 is associated to all virtqueue
groups by default. All virtqueues share the same mapping by default.

To demonstrate the function, VIRITO_NET_F_CTRL_MACADDR is
implemented in the simulator for the driver to set mac address.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 189 +++
 1 file changed, 166 insertions(+), 23 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index fe90a783bde4..0fd06ac491cd 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -60,14 +60,18 @@ struct vdpasim_virtqueue {
 #define VDPASIM_QUEUE_MAX 256
 #define VDPASIM_DEVICE_ID 0x1
 #define VDPASIM_VENDOR_ID 0
-#define VDPASIM_VQ_NUM 0x2
+#define VDPASIM_VQ_NUM 0x3
+#define VDPASIM_AS_NUM 0x2
+#define VDPASIM_GROUP_NUM 0x2
 #define VDPASIM_NAME "vdpasim-netdev"
 
 static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
  (1ULL << VIRTIO_F_VERSION_1)  |
  (1ULL << VIRTIO_F_ACCESS_PLATFORM) |
+ (1ULL << VIRTIO_NET_F_MTU) |
  (1ULL << VIRTIO_NET_F_MAC) |
- (1ULL << VIRTIO_NET_F_MTU);
+ (1ULL << VIRTIO_NET_F_CTRL_VQ) |
+ (1ULL << VIRTIO_NET_F_CTRL_MAC_ADDR);
 
 /* State of each vdpasim device */
 struct vdpasim {
@@ -147,11 +151,17 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
 {
int i;
 
-   for (i = 0; i < VDPASIM_VQ_NUM; i++)
+   spin_lock(>iommu_lock);
+
+   for (i = 0; i < VDPASIM_VQ_NUM; i++) {
vdpasim_vq_reset(>vqs[i]);
+   vringh_set_iotlb(>vqs[i].vring,
+>iommu[0]);
+   }
 
-   spin_lock(>iommu_lock);
-   vhost_iotlb_reset(vdpasim->iommu);
+   for (i = 0; i < VDPASIM_AS_NUM; i++) {
+   vhost_iotlb_reset(>iommu[i]);
+   }
spin_unlock(>iommu_lock);
 
vdpasim->features = 0;
@@ -191,6 +201,81 @@ static bool receive_filter(struct vdpasim *vdpasim, size_t 
len)
return false;
 }
 
+virtio_net_ctrl_ack vdpasim_handle_ctrl_mac(struct vdpasim *vdpasim,
+   u8 cmd)
+{
+   struct vdpasim_virtqueue *cvq = >vqs[2];
+   virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
+   size_t read;
+
+   switch (cmd) {
+   case VIRTIO_NET_CTRL_MAC_ADDR_SET:
+   read = vringh_iov_pull_iotlb(>vring, >in_iov,
+(void *)vdpasim->config.mac,
+ETH_ALEN);
+   if (read == ETH_ALEN)
+   status = VIRTIO_NET_OK;
+   break;
+   default:
+   break;
+   }
+
+   return status;
+}
+
+static void vdpasim_handle_cvq(struct vdpasim *vdpasim)
+{
+   struct vdpasim_virtqueue *cvq = >vqs[2];
+   virtio_net_ctrl_ack status = VIRTIO_NET_ERR;
+   struct virtio_net_ctrl_hdr ctrl;
+   size_t read, write;
+   int err;
+
+   if (!(vdpasim->features & (1ULL << VIRTIO_NET_F_CTRL_VQ)))
+   return;
+
+   if (!cvq->ready)
+   return;
+
+   while (true) {
+   err = vringh_getdesc_iotlb(>vring, >in_iov,
+  >out_iov,
+  >head, GFP_ATOMIC);
+   if (err <= 0)
+   break;
+
+   read = vringh_iov_pull_iotlb(>vring, >in_iov, ,
+sizeof(ctrl));
+   if (read != sizeof(ctrl))
+   

[PATCH 20/21] vdpa_sim: filter destination mac address

2020-12-15 Thread Jason Wang
This patch implements a simple unicast filter for vDPA simulator.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 49 
 1 file changed, 31 insertions(+), 18 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index e901177c6dfe..fe90a783bde4 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -175,6 +175,22 @@ static void vdpasim_complete(struct vdpasim_virtqueue *vq, 
size_t len)
local_bh_enable();
 }
 
+static bool receive_filter(struct vdpasim *vdpasim, size_t len)
+{
+   bool modern = vdpasim->features & (1ULL << VIRTIO_F_VERSION_1);
+   size_t hdr_len = modern ? sizeof(struct virtio_net_hdr_v1) :
+ sizeof(struct virtio_net_hdr);
+
+   if (len < ETH_ALEN + hdr_len)
+   return false;
+
+   if (!strncmp(vdpasim->buffer + hdr_len,
+vdpasim->config.mac, ETH_ALEN))
+   return true;
+
+   return false;
+}
+
 static void vdpasim_work(struct work_struct *work)
 {
struct vdpasim *vdpasim = container_of(work, struct
@@ -182,7 +198,6 @@ static void vdpasim_work(struct work_struct *work)
struct vdpasim_virtqueue *txq = >vqs[1];
struct vdpasim_virtqueue *rxq = >vqs[0];
ssize_t read, write;
-   size_t total_write;
int pkts = 0;
int err;
 
@@ -195,36 +210,34 @@ static void vdpasim_work(struct work_struct *work)
goto out;
 
while (true) {
-   total_write = 0;
err = vringh_getdesc_iotlb(>vring, >out_iov, NULL,
   >head, GFP_ATOMIC);
if (err <= 0)
break;
 
+   read = vringh_iov_pull_iotlb(>vring, >out_iov,
+vdpasim->buffer,
+PAGE_SIZE);
+
+   if (!receive_filter(vdpasim, read)) {
+   vdpasim_complete(txq, 0);
+   continue;
+   }
+
err = vringh_getdesc_iotlb(>vring, NULL, >in_iov,
   >head, GFP_ATOMIC);
if (err <= 0) {
-   vringh_complete_iotlb(>vring, txq->head, 0);
+   vdpasim_complete(txq, 0);
break;
}
 
-   while (true) {
-   read = vringh_iov_pull_iotlb(>vring, >out_iov,
-vdpasim->buffer,
-PAGE_SIZE);
-   if (read <= 0)
-   break;
-
-   write = vringh_iov_push_iotlb(>vring, >in_iov,
- vdpasim->buffer, read);
-   if (write <= 0)
-   break;
-
-   total_write += write;
-   }
+   write = vringh_iov_push_iotlb(>vring, >in_iov,
+ vdpasim->buffer, read);
+   if (write <= 0)
+   break;
 
vdpasim_complete(txq, 0);
-   vdpasim_complete(rxq, total_write);
+   vdpasim_complete(rxq, write);
 
if (++pkts > 4) {
schedule_work(>work);
-- 
2.25.1



[PATCH 19/21] vdpa_sim: factor out buffer completion logic

2020-12-15 Thread Jason Wang
Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 33 +---
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 8d051cf25f0a..e901177c6dfe 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -159,6 +159,22 @@ static void vdpasim_reset(struct vdpasim *vdpasim)
++vdpasim->generation;
 }
 
+static void vdpasim_complete(struct vdpasim_virtqueue *vq, size_t len)
+{
+   /* Make sure data is wrote before advancing index */
+   smp_wmb();
+
+   vringh_complete_iotlb(>vring, vq->head, len);
+
+   /* Make sure used is visible before rasing the interrupt. */
+   smp_wmb();
+
+   local_bh_disable();
+   if (vq->cb)
+   vq->cb(vq->private);
+   local_bh_enable();
+}
+
 static void vdpasim_work(struct work_struct *work)
 {
struct vdpasim *vdpasim = container_of(work, struct
@@ -207,21 +223,8 @@ static void vdpasim_work(struct work_struct *work)
total_write += write;
}
 
-   /* Make sure data is wrote before advancing index */
-   smp_wmb();
-
-   vringh_complete_iotlb(>vring, txq->head, 0);
-   vringh_complete_iotlb(>vring, rxq->head, total_write);
-
-   /* Make sure used is visible before rasing the interrupt. */
-   smp_wmb();
-
-   local_bh_disable();
-   if (txq->cb)
-   txq->cb(txq->private);
-   if (rxq->cb)
-   rxq->cb(rxq->private);
-   local_bh_enable();
+   vdpasim_complete(txq, 0);
+   vdpasim_complete(rxq, total_write);
 
if (++pkts > 4) {
schedule_work(>work);
-- 
2.25.1



[PATCH 18/21] vdpa_sim: advertise VIRTIO_NET_F_MTU

2020-12-15 Thread Jason Wang
We've already reported maximum mtu via config space, so let's
advertise the feature.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index fe4888dfb70f..8d051cf25f0a 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -66,7 +66,8 @@ struct vdpasim_virtqueue {
 static u64 vdpasim_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
  (1ULL << VIRTIO_F_VERSION_1)  |
  (1ULL << VIRTIO_F_ACCESS_PLATFORM) |
- (1ULL << VIRTIO_NET_F_MAC);
+ (1ULL << VIRTIO_NET_F_MAC) |
+ (1ULL << VIRTIO_NET_F_MTU);
 
 /* State of each vdpasim device */
 struct vdpasim {
-- 
2.25.1



[PATCH 16/21] vhost-vdpa: support ASID based IOTLB API

2020-12-15 Thread Jason Wang
This patch extends the vhost-vdpa to support ASID based IOTLB API. The
vhost-vdpa device will allocated multple IOTLBs for vDPA device that
supports multiple address spaces. The IOTLBs and vDPA device memory
mappings is determined and maintained through ASID.

Note that we still don't support vDPA device with more than one
address spaces that depends on platform IOMMU. This work will be done
by moving the IOMMU logic from vhost-vDPA to vDPA device driver.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c  | 127 --
 drivers/vhost/vhost.c |   4 +-
 2 files changed, 99 insertions(+), 32 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index cd7c9a401a61..c4fda48d4273 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -28,7 +28,8 @@
 enum {
VHOST_VDPA_BACKEND_FEATURES =
(1ULL << VHOST_BACKEND_F_IOTLB_MSG_V2) |
-   (1ULL << VHOST_BACKEND_F_IOTLB_BATCH),
+   (1ULL << VHOST_BACKEND_F_IOTLB_BATCH) |
+   (1ULL << VHOST_BACKEND_F_IOTLB_ASID),
 };
 
 #define VHOST_VDPA_DEV_MAX (1U << MINORBITS)
@@ -57,13 +58,20 @@ struct vhost_vdpa {
struct eventfd_ctx *config_ctx;
int in_batch;
struct vdpa_iova_range range;
-   int used_as;
+   u32 batch_asid;
 };
 
 static DEFINE_IDA(vhost_vdpa_ida);
 
 static dev_t vhost_vdpa_major;
 
+static inline u32 iotlb_to_asid(struct vhost_iotlb *iotlb)
+{
+   struct vhost_vdpa_as *as = container_of(iotlb, struct
+   vhost_vdpa_as, iotlb);
+   return as->id;
+}
+
 static struct vhost_vdpa_as *asid_to_as(struct vhost_vdpa *v, u32 asid)
 {
struct hlist_head *head = >as[asid % VHOST_VDPA_IOTLB_BUCKETS];
@@ -76,6 +84,16 @@ static struct vhost_vdpa_as *asid_to_as(struct vhost_vdpa 
*v, u32 asid)
return NULL;
 }
 
+static struct vhost_iotlb *asid_to_iotlb(struct vhost_vdpa *v, u32 asid)
+{
+   struct vhost_vdpa_as *as = asid_to_as(v, asid);
+
+   if (!as)
+   return NULL;
+
+   return >iotlb;
+}
+
 static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct vhost_vdpa *v, u32 
asid)
 {
struct hlist_head *head = >as[asid % VHOST_VDPA_IOTLB_BUCKETS];
@@ -84,6 +102,9 @@ static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct 
vhost_vdpa *v, u32 asid)
if (asid_to_as(v, asid))
return NULL;
 
+   if (asid >= v->vdpa->nas)
+   return NULL;
+
as = kmalloc(sizeof(*as), GFP_KERNEL);
if (!as)
return NULL;
@@ -91,18 +112,24 @@ static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct 
vhost_vdpa *v, u32 asid)
vhost_iotlb_init(>iotlb, 0, 0);
as->id = asid;
hlist_add_head(>hash_link, head);
-   ++v->used_as;
 
return as;
 }
 
-static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 asid)
+static struct vhost_vdpa_as *vhost_vdpa_find_alloc_as(struct vhost_vdpa *v,
+ u32 asid)
 {
struct vhost_vdpa_as *as = asid_to_as(v, asid);
 
-   /* Remove default address space is not allowed */
-   if (asid == 0)
-   return -EINVAL;
+   if (as)
+   return as;
+
+   return vhost_vdpa_alloc_as(v, asid);
+}
+
+static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 asid)
+{
+   struct vhost_vdpa_as *as = asid_to_as(v, asid);
 
if (!as)
return -EINVAL;
@@ -110,7 +137,6 @@ static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 
asid)
hlist_del(>hash_link);
vhost_iotlb_reset(>iotlb);
kfree(as);
-   --v->used_as;
 
return 0;
 }
@@ -636,6 +662,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct 
vhost_iotlb *iotlb,
struct vhost_dev *dev = >vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
+   u32 asid = iotlb_to_asid(iotlb);
int r = 0;
 
r = vhost_iotlb_add_range(iotlb, iova, iova + size - 1,
@@ -644,10 +671,10 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct 
vhost_iotlb *iotlb,
return r;
 
if (ops->dma_map) {
-   r = ops->dma_map(vdpa, 0, iova, size, pa, perm);
+   r = ops->dma_map(vdpa, asid, iova, size, pa, perm);
} else if (ops->set_map) {
if (!v->in_batch)
-   r = ops->set_map(vdpa, 0, iotlb);
+   r = ops->set_map(vdpa, asid, iotlb);
} else {
r = iommu_map(v->domain, iova, pa, size,
  perm_to_iommu_flags(perm));
@@ -661,23 +688,35 @@ static int vhost_vdpa_map(struct vhost_vdpa *v, struct 
vhost_iotlb *iotlb,
return r;
 }
 
-static void vhost_vdpa_unmap(struct vhost_vdpa *v,
-struct vhost_iotlb *iotlb,
-u64 iova, u64 size)
+static int vhost_vdpa_unmap(struct vhost_vdpa *v,
+   

[PATCH 17/21] vdpa_sim: split vdpasim_virtqueue's iov field in out_iov and in_iov

2020-12-15 Thread Jason Wang
From: Stefano Garzarella 

vringh_getdesc_iotlb() manages 2 iovs for writable and readable
descriptors. This is very useful for the block device, where for
each request we have both types of descriptor.

Let's split the vdpasim_virtqueue's iov field in out_iov and
in_iov to use them with vringh_getdesc_iotlb().

We are using VIRTIO terminology for "out" (readable by the device)
and "in" (writable by the device) descriptors.

Acked-by: Jason Wang 
Signed-off-by: Stefano Garzarella 
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 140de452..fe4888dfb70f 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -44,7 +44,8 @@ MODULE_PARM_DESC(macaddr, "Ethernet MAC address");
 
 struct vdpasim_virtqueue {
struct vringh vring;
-   struct vringh_kiov iov;
+   struct vringh_kiov in_iov;
+   struct vringh_kiov out_iov;
unsigned short head;
bool ready;
u64 desc_addr;
@@ -178,12 +179,12 @@ static void vdpasim_work(struct work_struct *work)
 
while (true) {
total_write = 0;
-   err = vringh_getdesc_iotlb(>vring, >iov, NULL,
+   err = vringh_getdesc_iotlb(>vring, >out_iov, NULL,
   >head, GFP_ATOMIC);
if (err <= 0)
break;
 
-   err = vringh_getdesc_iotlb(>vring, NULL, >iov,
+   err = vringh_getdesc_iotlb(>vring, NULL, >in_iov,
   >head, GFP_ATOMIC);
if (err <= 0) {
vringh_complete_iotlb(>vring, txq->head, 0);
@@ -191,13 +192,13 @@ static void vdpasim_work(struct work_struct *work)
}
 
while (true) {
-   read = vringh_iov_pull_iotlb(>vring, >iov,
+   read = vringh_iov_pull_iotlb(>vring, >out_iov,
 vdpasim->buffer,
 PAGE_SIZE);
if (read <= 0)
break;
 
-   write = vringh_iov_push_iotlb(>vring, >iov,
+   write = vringh_iov_push_iotlb(>vring, >in_iov,
  vdpasim->buffer, read);
if (write <= 0)
break;
-- 
2.25.1



[PATCH 15/21] vhost-vdpa: introduce uAPI to set group ASID

2020-12-15 Thread Jason Wang
Follows the vDPA support for associating ASID to a specific virtqueue
group. This patch adds a uAPI to support setting them from userspace.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c   | 8 
 include/uapi/linux/vhost.h | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index e7023abda12c..cd7c9a401a61 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -450,6 +450,14 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
else if (copy_to_user(argp, , sizeof s))
return -EFAULT;
return 0;
+   case VHOST_VDPA_SET_GROUP_ASID:
+   if (copy_from_user(, argp, sizeof(s)))
+   return -EFAULT;
+   if (s.num >= vdpa->nas)
+   return -EINVAL;
+   if (!ops->set_group_asid)
+   return -ENOTSUPP;
+   return ops->set_group_asid(vdpa, idx, s.num);
case VHOST_GET_VRING_BASE:
r = ops->get_vq_state(v->vdpa, idx, _state);
if (r)
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 99de06476fdc..5e083490f1aa 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -158,4 +158,11 @@
  */
 #define VHOST_VDPA_GET_VRING_GROUP _IOWR(VHOST_VIRTIO, 0x7B,   \
  struct vhost_vring_state)
+/* Set the ASID for a virtqueue group. The group index is stored in
+ * the index field of vhost_vring_state, the ASID associated with this
+ * group is stored at num field of vhost_vring_state.
+ */
+#define VHOST_VDPA_SET_GROUP_ASID  _IOW(VHOST_VIRTIO, 0x7C, \
+struct vhost_vring_state)
+
 #endif
-- 
2.25.1



[PATCH 14/21] vhost-vdpa: uAPI to get virtqueue group id

2020-12-15 Thread Jason Wang
Follows the support for virtqueue group in vDPA. This patches
introduces uAPI to get the virtqueue group ID for a specific virtqueue
in vhost-vdpa.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c   | 8 
 include/uapi/linux/vhost.h | 8 
 2 files changed, 16 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index bff8aa214f78..e7023abda12c 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -442,6 +442,14 @@ static long vhost_vdpa_vring_ioctl(struct vhost_vdpa *v, 
unsigned int cmd,
return -EFAULT;
ops->set_vq_ready(vdpa, idx, s.num);
return 0;
+   case VHOST_VDPA_GET_VRING_GROUP:
+   s.index = idx;
+   s.num = ops->get_vq_group(vdpa, idx);
+   if (s.num >= vdpa->ngroups)
+   return -EIO;
+   else if (copy_to_user(argp, , sizeof s))
+   return -EFAULT;
+   return 0;
case VHOST_GET_VRING_BASE:
r = ops->get_vq_state(v->vdpa, idx, _state);
if (r)
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 8762911a3cb8..99de06476fdc 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -150,4 +150,12 @@
 
 /* Get the number of address spaces. */
 #define VHOST_VDPA_GET_AS_NUM  _IOR(VHOST_VIRTIO, 0x7A, unsigned int)
+
+/* Get the group for a virtqueue: read index, write group in num,
+ * The virtqueue index is stored in the index field of
+ * vhost_vring_state. The group for this specific virtqueue is
+ * returned via num field of vhost_vring_state.
+ */
+#define VHOST_VDPA_GET_VRING_GROUP _IOWR(VHOST_VIRTIO, 0x7B,   \
+ struct vhost_vring_state)
 #endif
-- 
2.25.1



[PATCH 13/21] vhost-vdpa: introduce uAPI to get the number of address spaces

2020-12-15 Thread Jason Wang
This patch introduces the uAPI for getting the number of address
spaces supported by this vDPA device.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c   | 3 +++
 include/uapi/linux/vhost.h | 2 ++
 2 files changed, 5 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 1ba5901b28e7..bff8aa214f78 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -540,6 +540,9 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
r = copy_to_user(argp, >vdpa->ngroups,
 sizeof(v->vdpa->ngroups));
break;
+   case VHOST_VDPA_GET_AS_NUM:
+   r = copy_to_user(argp, >vdpa->nas, sizeof(v->vdpa->nas));
+   break;
case VHOST_SET_LOG_BASE:
case VHOST_SET_LOG_FD:
r = -ENOIOCTLCMD;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 8a4e6e426bbf..8762911a3cb8 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -148,4 +148,6 @@
 /* Get the number of virtqueue groups. */
 #define VHOST_VDPA_GET_GROUP_NUM   _IOR(VHOST_VIRTIO, 0x79, unsigned int)
 
+/* Get the number of address spaces. */
+#define VHOST_VDPA_GET_AS_NUM  _IOR(VHOST_VIRTIO, 0x7A, unsigned int)
 #endif
-- 
2.25.1



[PATCH 12/21] vhost-vdpa: introduce uAPI to get the number of virtqueue groups

2020-12-15 Thread Jason Wang
Follows the vDPA support for multiple address spaces, this patch
introduce uAPI for the userspace to know the number of virtqueue
groups supported by the vDPA device.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c   | 4 
 include/uapi/linux/vhost.h | 3 +++
 2 files changed, 7 insertions(+)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 060d5b5b7e64..1ba5901b28e7 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -536,6 +536,10 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
case VHOST_VDPA_GET_VRING_NUM:
r = vhost_vdpa_get_vring_num(v, argp);
break;
+   case VHOST_VDPA_GET_GROUP_NUM:
+   r = copy_to_user(argp, >vdpa->ngroups,
+sizeof(v->vdpa->ngroups));
+   break;
case VHOST_SET_LOG_BASE:
case VHOST_SET_LOG_FD:
r = -ENOIOCTLCMD;
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 59c6c0fbaba1..8a4e6e426bbf 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -145,4 +145,7 @@
 /* Get the valid iova range */
 #define VHOST_VDPA_GET_IOVA_RANGE  _IOR(VHOST_VIRTIO, 0x78, \
 struct vhost_vdpa_iova_range)
+/* Get the number of virtqueue groups. */
+#define VHOST_VDPA_GET_GROUP_NUM   _IOR(VHOST_VIRTIO, 0x79, unsigned int)
+
 #endif
-- 
2.25.1



[PATCH 11/21] vhost-vdpa: introduce asid based IOTLB

2020-12-15 Thread Jason Wang
This patch converts the vhost-vDPA device to support multiple IOTLBs
tagged via ASID via hlist. This will be used for supporting multiple
address spaces in the following patches.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 106 ---
 1 file changed, 80 insertions(+), 26 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index feb6a58df22d..060d5b5b7e64 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -33,13 +33,21 @@ enum {
 
 #define VHOST_VDPA_DEV_MAX (1U << MINORBITS)
 
+#define VHOST_VDPA_IOTLB_BUCKETS 16
+
+struct vhost_vdpa_as {
+   struct hlist_node hash_link;
+   struct vhost_iotlb iotlb;
+   u32 id;
+};
+
 struct vhost_vdpa {
struct vhost_dev vdev;
struct iommu_domain *domain;
struct vhost_virtqueue *vqs;
struct completion completion;
struct vdpa_device *vdpa;
-   struct vhost_iotlb *iotlb;
+   struct hlist_head as[VHOST_VDPA_IOTLB_BUCKETS];
struct device dev;
struct cdev cdev;
atomic_t opened;
@@ -49,12 +57,64 @@ struct vhost_vdpa {
struct eventfd_ctx *config_ctx;
int in_batch;
struct vdpa_iova_range range;
+   int used_as;
 };
 
 static DEFINE_IDA(vhost_vdpa_ida);
 
 static dev_t vhost_vdpa_major;
 
+static struct vhost_vdpa_as *asid_to_as(struct vhost_vdpa *v, u32 asid)
+{
+   struct hlist_head *head = >as[asid % VHOST_VDPA_IOTLB_BUCKETS];
+   struct vhost_vdpa_as *as;
+
+   hlist_for_each_entry(as, head, hash_link)
+   if (as->id == asid)
+   return as;
+
+   return NULL;
+}
+
+static struct vhost_vdpa_as *vhost_vdpa_alloc_as(struct vhost_vdpa *v, u32 
asid)
+{
+   struct hlist_head *head = >as[asid % VHOST_VDPA_IOTLB_BUCKETS];
+   struct vhost_vdpa_as *as;
+
+   if (asid_to_as(v, asid))
+   return NULL;
+
+   as = kmalloc(sizeof(*as), GFP_KERNEL);
+   if (!as)
+   return NULL;
+
+   vhost_iotlb_init(>iotlb, 0, 0);
+   as->id = asid;
+   hlist_add_head(>hash_link, head);
+   ++v->used_as;
+
+   return as;
+}
+
+static int vhost_vdpa_remove_as(struct vhost_vdpa *v, u32 asid)
+{
+   struct vhost_vdpa_as *as = asid_to_as(v, asid);
+
+   /* Remove default address space is not allowed */
+   if (asid == 0)
+   return -EINVAL;
+
+   if (!as)
+   return -EINVAL;
+
+   hlist_del(>hash_link);
+   vhost_iotlb_reset(>iotlb);
+   kfree(as);
+   --v->used_as;
+
+   return 0;
+}
+
 static void handle_vq_kick(struct vhost_work *work)
 {
struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
@@ -525,15 +585,6 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
}
 }
 
-static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
-{
-   struct vhost_iotlb *iotlb = v->iotlb;
-
-   vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1);
-   kfree(v->iotlb);
-   v->iotlb = NULL;
-}
-
 static int perm_to_iommu_flags(u32 perm)
 {
int flags = 0;
@@ -745,7 +796,8 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev 
*dev, u32 asid,
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
-   struct vhost_iotlb *iotlb = v->iotlb;
+   struct vhost_vdpa_as *as = asid_to_as(v, 0);
+   struct vhost_iotlb *iotlb = >iotlb;
int r = 0;
 
if (asid != 0)
@@ -856,6 +908,13 @@ static void vhost_vdpa_set_iova_range(struct vhost_vdpa *v)
}
 }
 
+static void vhost_vdpa_cleanup(struct vhost_vdpa *v)
+{
+   vhost_dev_cleanup(>vdev);
+   kfree(v->vdev.vqs);
+   vhost_vdpa_remove_as(v, 0);
+}
+
 static int vhost_vdpa_open(struct inode *inode, struct file *filep)
 {
struct vhost_vdpa *v;
@@ -886,15 +945,12 @@ static int vhost_vdpa_open(struct inode *inode, struct 
file *filep)
vhost_dev_init(dev, vqs, nvqs, 0, 0, 0, false,
   vhost_vdpa_process_iotlb_msg);
 
-   v->iotlb = vhost_iotlb_alloc(0, 0);
-   if (!v->iotlb) {
-   r = -ENOMEM;
-   goto err_init_iotlb;
-   }
+   if (!vhost_vdpa_alloc_as(v, 0))
+   goto err_alloc_as;
 
r = vhost_vdpa_alloc_domain(v);
if (r)
-   goto err_alloc_domain;
+   goto err_alloc_as;
 
vhost_vdpa_set_iova_range(v);
 
@@ -902,11 +958,8 @@ static int vhost_vdpa_open(struct inode *inode, struct 
file *filep)
 
return 0;
 
-err_alloc_domain:
-   vhost_vdpa_iotlb_free(v);
-err_init_iotlb:
-   vhost_dev_cleanup(>vdev);
-   kfree(vqs);
+err_alloc_as:
+   vhost_vdpa_cleanup(v);
 err:
atomic_dec(>opened);
return r;
@@ -933,12 +986,10 @@ static int vhost_vdpa_release(struct inode *inode, struct 
file *filep)
filep->private_data = NULL;

[PATCH 10/21] vhost: support ASID in IOTLB API

2020-12-15 Thread Jason Wang
This patches allows userspace to send ASID based IOTLB message to
vhost. This idea is to use the reserved u32 field in the existing V2
IOTLB message. Vhost device should advertise this capability via
VHOST_BACKEND_F_IOTLB_ASID backend feature.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c |  5 -
 drivers/vhost/vhost.c| 23 ++-
 drivers/vhost/vhost.h|  4 ++--
 include/uapi/linux/vhost_types.h |  5 -
 4 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 03a9b3311c6c..feb6a58df22d 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -739,7 +739,7 @@ static int vhost_vdpa_process_iotlb_update(struct 
vhost_vdpa *v,
return ret;
 }
 
-static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev,
+static int vhost_vdpa_process_iotlb_msg(struct vhost_dev *dev, u32 asid,
struct vhost_iotlb_msg *msg)
 {
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
@@ -748,6 +748,9 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev 
*dev,
struct vhost_iotlb *iotlb = v->iotlb;
int r = 0;
 
+   if (asid != 0)
+   return -EINVAL;
+
r = vhost_dev_check_owner(dev);
if (r)
return r;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index a262e12c6dc2..7477b724c29b 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -468,7 +468,7 @@ void vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue **vqs, int nvqs,
int iov_limit, int weight, int byte_weight,
bool use_worker,
-   int (*msg_handler)(struct vhost_dev *dev,
+   int (*msg_handler)(struct vhost_dev *dev, u32 asid,
   struct vhost_iotlb_msg *msg))
 {
struct vhost_virtqueue *vq;
@@ -1084,11 +1084,14 @@ static bool umem_access_ok(u64 uaddr, u64 size, int 
access)
return true;
 }
 
-static int vhost_process_iotlb_msg(struct vhost_dev *dev,
+static int vhost_process_iotlb_msg(struct vhost_dev *dev, u16 asid,
   struct vhost_iotlb_msg *msg)
 {
int ret = 0;
 
+   if (asid != 0)
+   return -EINVAL;
+
mutex_lock(>mutex);
vhost_dev_lock_vqs(dev);
switch (msg->type) {
@@ -1135,6 +1138,7 @@ ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
struct vhost_iotlb_msg msg;
size_t offset;
int type, ret;
+   u16 asid = 0;
 
ret = copy_from_iter(, sizeof(type), from);
if (ret != sizeof(type)) {
@@ -1150,7 +1154,16 @@ ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
offset = offsetof(struct vhost_msg, iotlb) - sizeof(int);
break;
case VHOST_IOTLB_MSG_V2:
-   offset = sizeof(__u32);
+   if (vhost_backend_has_feature(dev->vqs[0],
+ VHOST_BACKEND_F_IOTLB_ASID)) {
+   ret = copy_from_iter(, sizeof(asid), from);
+   if (ret != sizeof(asid)) {
+   ret = -EINVAL;
+   goto done;
+   }
+   offset = sizeof(__u16);
+   } else
+   offset = sizeof(__u32);
break;
default:
ret = -EINVAL;
@@ -1165,9 +1178,9 @@ ssize_t vhost_chr_write_iter(struct vhost_dev *dev,
}
 
if (dev->msg_handler)
-   ret = dev->msg_handler(dev, );
+   ret = dev->msg_handler(dev, asid, );
else
-   ret = vhost_process_iotlb_msg(dev, );
+   ret = vhost_process_iotlb_msg(dev, asid, );
if (ret) {
ret = -EFAULT;
goto done;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index b063324c7669..19753a90875c 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -162,7 +162,7 @@ struct vhost_dev {
int byte_weight;
u64 kcov_handle;
bool use_worker;
-   int (*msg_handler)(struct vhost_dev *dev,
+   int (*msg_handler)(struct vhost_dev *dev, u32 asid,
   struct vhost_iotlb_msg *msg);
 };
 
@@ -170,7 +170,7 @@ bool vhost_exceeds_weight(struct vhost_virtqueue *vq, int 
pkts, int total_len);
 void vhost_dev_init(struct vhost_dev *, struct vhost_virtqueue **vqs,
int nvqs, int iov_limit, int weight, int byte_weight,
bool use_worker,
-   int (*msg_handler)(struct vhost_dev *dev,
+   int (*msg_handler)(struct vhost_dev *dev, u32 asid,
   struct vhost_iotlb_msg *msg));
 long vhost_dev_set_owner(struct vhost_dev *dev);
 bool vhost_dev_has_owner(struct vhost_dev *dev);
diff --git 

[PATCH 09/21] vhost_iotlb: split out IOTLB initialization

2020-12-15 Thread Jason Wang
This patch splits out IOTLB initialization to make sure it could be
reused by external modules.

Signed-off-by: Jason Wang 
---
 drivers/vhost/iotlb.c   | 23 ++-
 include/linux/vhost_iotlb.h |  2 ++
 2 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/vhost/iotlb.c b/drivers/vhost/iotlb.c
index 0fd3f87e913c..e842d76c179e 100644
--- a/drivers/vhost/iotlb.c
+++ b/drivers/vhost/iotlb.c
@@ -98,6 +98,23 @@ void vhost_iotlb_del_range(struct vhost_iotlb *iotlb, u64 
start, u64 last)
 }
 EXPORT_SYMBOL_GPL(vhost_iotlb_del_range);
 
+/**
+ * vhost_iotlb_init - initialize a vhost IOTLB
+ * @iotlb: the IOTLB that needs to be initialized
+ * @limit: maximum number of IOTLB entries
+ * @flags: VHOST_IOTLB_FLAG_XXX
+ */
+void vhost_iotlb_init(struct vhost_iotlb *iotlb, unsigned int limit,
+ unsigned int flags)
+{
+   iotlb->root = RB_ROOT_CACHED;
+   iotlb->limit = limit;
+   iotlb->nmaps = 0;
+   iotlb->flags = flags;
+   INIT_LIST_HEAD(>list);
+}
+EXPORT_SYMBOL_GPL(vhost_iotlb_init);
+
 /**
  * vhost_iotlb_alloc - add a new vhost IOTLB
  * @limit: maximum number of IOTLB entries
@@ -112,11 +129,7 @@ struct vhost_iotlb *vhost_iotlb_alloc(unsigned int limit, 
unsigned int flags)
if (!iotlb)
return NULL;
 
-   iotlb->root = RB_ROOT_CACHED;
-   iotlb->limit = limit;
-   iotlb->nmaps = 0;
-   iotlb->flags = flags;
-   INIT_LIST_HEAD(>list);
+   vhost_iotlb_init(iotlb, limit, flags);
 
return iotlb;
 }
diff --git a/include/linux/vhost_iotlb.h b/include/linux/vhost_iotlb.h
index 6b09b786a762..c0df193ec3e1 100644
--- a/include/linux/vhost_iotlb.h
+++ b/include/linux/vhost_iotlb.h
@@ -33,6 +33,8 @@ int vhost_iotlb_add_range(struct vhost_iotlb *iotlb, u64 
start, u64 last,
  u64 addr, unsigned int perm);
 void vhost_iotlb_del_range(struct vhost_iotlb *iotlb, u64 start, u64 last);
 
+void vhost_iotlb_init(struct vhost_iotlb *iotlb, unsigned int limit,
+ unsigned int flags);
 struct vhost_iotlb *vhost_iotlb_alloc(unsigned int limit, unsigned int flags);
 void vhost_iotlb_free(struct vhost_iotlb *iotlb);
 void vhost_iotlb_reset(struct vhost_iotlb *iotlb);
-- 
2.25.1



[PATCH v2] venus: venc: set inband mode property to FW.

2020-12-15 Thread Dikshita Agarwal
set HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER to FW
to support inband sequence header mode.

Signed-off-by: Dikshita Agarwal 

Changes since v1:
- added codec check 
- fixed the mask while initializing the control

---
 drivers/media/platform/qcom/venus/venc_ctrls.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc_ctrls.c 
b/drivers/media/platform/qcom/venus/venc_ctrls.c
index cf860e6..a94f5fd 100644
--- a/drivers/media/platform/qcom/venus/venc_ctrls.c
+++ b/drivers/media/platform/qcom/venus/venc_ctrls.c
@@ -157,7 +157,17 @@ static int venc_op_s_ctrl(struct v4l2_ctrl *ctrl)
ctr->h264_loop_filter_mode = ctrl->val;
break;
case V4L2_CID_MPEG_VIDEO_HEADER_MODE:
-   ctr->header_mode = ctrl->val;
+   if (inst->fmt_cap->pixfmt == V4L2_PIX_FMT_H264 ||
+   inst->fmt_cap->pixfmt == V4L2_PIX_FMT_HEVC) {
+   if (ctrl->val == V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE)
+   en.enable = 0;
+   else
+   en.enable = 1;
+   ptype = 
HFI_PROPERTY_CONFIG_VENC_SYNC_FRAME_SEQUENCE_HEADER;
+   ret = hfi_session_set_property(inst, ptype, );
+   if (ret)
+   return ret;
+   }
break;
case V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB:
break;
@@ -289,7 +299,8 @@ int venc_ctrl_init(struct venus_inst *inst)
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
V4L2_CID_MPEG_VIDEO_HEADER_MODE,
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
-   1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME,
+   ~((1 << V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE) |
+   (1 << V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME)),
V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE);
 
v4l2_ctrl_new_std_menu(>ctrl_handler, _ctrl_ops,
-- 
2.7.4



[PATCH 08/21] vdpa: introduce config operations for associating ASID to a virtqueue group

2020-12-15 Thread Jason Wang
This patch introduces a new bus operation to allow the vDPA bus driver
to associate an ASID to a virtqueue group.

Signed-off-by: Jason Wang 
---
 include/linux/vdpa.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 0a9a754f8180..2a8671f27b0b 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -174,6 +174,12 @@ struct vdpa_iova_range {
  * @vdev: vdpa device
  * Returns the iova range supported by
  * the device.
+ * @set_group_asid:Set address space identifier for a
+ * virtqueue group
+ * @vdev: vdpa device
+ * @group: virtqueue group
+ * @asid: address space id for this group
+ * Returns integer: success (0) or error (< 0)
  * @set_map:   Set device memory mapping (optional)
  * Needed for device that using device
  * specific DMA translation (on-chip IOMMU)
@@ -252,6 +258,10 @@ struct vdpa_config_ops {
   u64 iova, u64 size, u64 pa, u32 perm);
int (*dma_unmap)(struct vdpa_device *vdev, unsigned int asid,
 u64 iova, u64 size);
+   int (*set_group_asid)(struct vdpa_device *vdev, unsigned int group,
+ unsigned int asid);
+
+
 
/* Free device resources */
void (*free)(struct vdpa_device *vdev);
-- 
2.25.1



[PATCH 07/21] vdpa: multiple address spaces support

2020-12-15 Thread Jason Wang
This patches introduces the multiple address spaces support for vDPA
device. This idea is to identify a specific address space via an
dedicated identifier - ASID.

During vDPA device allocation, vDPA device driver needs to report the
number of address spaces supported by the device then the DMA mapping
ops of the vDPA device needs to be extended to support ASID.

This helps to isolate the environments for the virtqueue that will not
be assigned directly. E.g in the case of virtio-net, the control
virtqueue will not be assigned directly to guest.

As a start, simply claim 1 virtqueue groups and 1 address spaces for
all vDPA devices. And vhost-vDPA will simply reject the device with
more than 1 virtqueue groups or address spaces.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/ifcvf/ifcvf_main.c   |  2 +-
 drivers/vdpa/mlx5/net/mlx5_vnet.c |  5 +++--
 drivers/vdpa/vdpa.c   |  4 +++-
 drivers/vdpa/vdpa_sim/vdpa_sim.c  | 10 ++
 drivers/vhost/vdpa.c  | 14 +-
 include/linux/vdpa.h  | 23 ---
 6 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index c629f4fcc738..8a43f562b169 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -445,7 +445,7 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
dev, _vdpa_ops,
-   IFCVF_MAX_QUEUE_PAIRS * 2, 1);
+   IFCVF_MAX_QUEUE_PAIRS * 2, 1, 1);
 
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 719b52fcc547..7aaf0a4ee80d 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1804,7 +1804,8 @@ static u32 mlx5_vdpa_get_generation(struct vdpa_device 
*vdev)
return mvdev->generation;
 }
 
-static int mlx5_vdpa_set_map(struct vdpa_device *vdev, struct vhost_iotlb 
*iotlb)
+static int mlx5_vdpa_set_map(struct vdpa_device *vdev, unsigned int asid,
+struct vhost_iotlb *iotlb)
 {
struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
@@ -1947,7 +1948,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
 
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, 
mdev->device, _vdpa_ops,
-2 * mlx5_vdpa_max_qps(max_vqs), 1);
+2 * mlx5_vdpa_max_qps(max_vqs), 1, 1);
if (IS_ERR(ndev))
return ndev;
 
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index 46399746ec7c..05195fa7865d 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -63,6 +63,7 @@ static void vdpa_release_dev(struct device *d)
  * @config: the bus operations that is supported by this device
  * @nvqs: number of virtqueues supported by this device
  * @ngroups: number of groups supported by this device
+ * @nas: number of address spaces supported by this device
  * @size: size of the parent structure that contains private data
  *
  * Driver should use vdpa_alloc_device() wrapper macro instead of
@@ -74,7 +75,7 @@ static void vdpa_release_dev(struct device *d)
 struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
int nvqs, unsigned int ngroups,
-   size_t size)
+   unsigned int nas, size_t size)
 {
struct vdpa_device *vdev;
int err = -EINVAL;
@@ -102,6 +103,7 @@ struct vdpa_device *__vdpa_alloc_device(struct device 
*parent,
vdev->features_valid = false;
vdev->nvqs = nvqs;
vdev->ngroups = ngroups;
+   vdev->nas = nas;
 
err = dev_set_name(>dev, "vdpa%u", vdev->index);
if (err)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c b/drivers/vdpa/vdpa_sim/vdpa_sim.c
index 5d554b3cd152..140de452 100644
--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -359,7 +359,7 @@ static struct vdpasim *vdpasim_create(void)
ops = _net_config_ops;
 
vdpasim = vdpa_alloc_device(struct vdpasim, vdpa, NULL, ops,
-   VDPASIM_VQ_NUM, 1);
+   VDPASIM_VQ_NUM, 1, 1);
if (!vdpasim)
goto err_alloc;
 
@@ -606,7 +606,7 @@ static struct vdpa_iova_range vdpasim_get_iova_range(struct 
vdpa_device *vdpa)
return range;
 }
 
-static int vdpasim_set_map(struct vdpa_device *vdpa,
+static int vdpasim_set_map(struct vdpa_device *vdpa, unsigned 

[PATCH 06/21] vdpa: introduce virtqueue groups

2020-12-15 Thread Jason Wang
This patch introduces virtqueue groups to vDPA device. The virtqueue
group is the minimal set of virtqueues that must share an address
space. And the adddress space identifier could only be attached to
a specific virtqueue group.

A new mandated bus operation is introduced to get the virtqueue group
ID for a specific virtqueue.

All the vDPA device drivers were converted to simply support a single
virtqueue group.

Signed-off-by: Jason Wang 
---
 drivers/vdpa/ifcvf/ifcvf_main.c   |  9 -
 drivers/vdpa/mlx5/net/mlx5_vnet.c |  8 +++-
 drivers/vdpa/vdpa.c   |  4 +++-
 drivers/vdpa/vdpa_sim/vdpa_sim.c  | 11 ++-
 include/linux/vdpa.h  | 12 +---
 5 files changed, 37 insertions(+), 7 deletions(-)

diff --git a/drivers/vdpa/ifcvf/ifcvf_main.c b/drivers/vdpa/ifcvf/ifcvf_main.c
index 8b4028556cb6..c629f4fcc738 100644
--- a/drivers/vdpa/ifcvf/ifcvf_main.c
+++ b/drivers/vdpa/ifcvf/ifcvf_main.c
@@ -332,6 +332,11 @@ static u32 ifcvf_vdpa_get_vq_align(struct vdpa_device 
*vdpa_dev)
return IFCVF_QUEUE_ALIGNMENT;
 }
 
+static u32 ifcvf_vdpa_get_vq_group(struct vdpa_device *vdpa, u16 idx)
+{
+   return 0;
+}
+
 static void ifcvf_vdpa_get_config(struct vdpa_device *vdpa_dev,
  unsigned int offset,
  void *buf, unsigned int len)
@@ -392,6 +397,7 @@ static const struct vdpa_config_ops ifc_vdpa_ops = {
.get_device_id  = ifcvf_vdpa_get_device_id,
.get_vendor_id  = ifcvf_vdpa_get_vendor_id,
.get_vq_align   = ifcvf_vdpa_get_vq_align,
+   .get_vq_group   = ifcvf_vdpa_get_vq_group,
.get_config = ifcvf_vdpa_get_config,
.set_config = ifcvf_vdpa_set_config,
.set_config_cb  = ifcvf_vdpa_set_config_cb,
@@ -439,7 +445,8 @@ static int ifcvf_probe(struct pci_dev *pdev, const struct 
pci_device_id *id)
 
adapter = vdpa_alloc_device(struct ifcvf_adapter, vdpa,
dev, _vdpa_ops,
-   IFCVF_MAX_QUEUE_PAIRS * 2);
+   IFCVF_MAX_QUEUE_PAIRS * 2, 1);
+
if (adapter == NULL) {
IFCVF_ERR(pdev, "Failed to allocate vDPA structure");
return -ENOMEM;
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c 
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 1fa6fcac8299..719b52fcc547 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1436,6 +1436,11 @@ static u32 mlx5_vdpa_get_vq_align(struct vdpa_device 
*vdev)
return PAGE_SIZE;
 }
 
+static u32 mlx5_vdpa_get_vq_group(struct vdpa_device *vdpa, u16 idx)
+{
+   return 0;
+}
+
 enum { MLX5_VIRTIO_NET_F_GUEST_CSUM = 1 << 9,
MLX5_VIRTIO_NET_F_CSUM = 1 << 10,
MLX5_VIRTIO_NET_F_HOST_TSO6 = 1 << 11,
@@ -1854,6 +1859,7 @@ static const struct vdpa_config_ops mlx5_vdpa_ops = {
.get_vq_notification = mlx5_get_vq_notification,
.get_vq_irq = mlx5_get_vq_irq,
.get_vq_align = mlx5_vdpa_get_vq_align,
+   .get_vq_group = mlx5_vdpa_get_vq_group,
.get_features = mlx5_vdpa_get_features,
.set_features = mlx5_vdpa_set_features,
.set_config_cb = mlx5_vdpa_set_config_cb,
@@ -1941,7 +1947,7 @@ void *mlx5_vdpa_add_dev(struct mlx5_core_dev *mdev)
max_vqs = min_t(u32, max_vqs, MLX5_MAX_SUPPORTED_VQS);
 
ndev = vdpa_alloc_device(struct mlx5_vdpa_net, mvdev.vdev, 
mdev->device, _vdpa_ops,
-2 * mlx5_vdpa_max_qps(max_vqs));
+2 * mlx5_vdpa_max_qps(max_vqs), 1);
if (IS_ERR(ndev))
return ndev;
 
diff --git a/drivers/vdpa/vdpa.c b/drivers/vdpa/vdpa.c
index a69ffc991e13..46399746ec7c 100644
--- a/drivers/vdpa/vdpa.c
+++ b/drivers/vdpa/vdpa.c
@@ -62,6 +62,7 @@ static void vdpa_release_dev(struct device *d)
  * @parent: the parent device
  * @config: the bus operations that is supported by this device
  * @nvqs: number of virtqueues supported by this device
+ * @ngroups: number of groups supported by this device
  * @size: size of the parent structure that contains private data
  *
  * Driver should use vdpa_alloc_device() wrapper macro instead of
@@ -72,7 +73,7 @@ static void vdpa_release_dev(struct device *d)
  */
 struct vdpa_device *__vdpa_alloc_device(struct device *parent,
const struct vdpa_config_ops *config,
-   int nvqs,
+   int nvqs, unsigned int ngroups,
size_t size)
 {
struct vdpa_device *vdev;
@@ -100,6 +101,7 @@ struct vdpa_device *__vdpa_alloc_device(struct device 
*parent,
vdev->config = config;
vdev->features_valid = false;
vdev->nvqs = nvqs;
+   vdev->ngroups = ngroups;
 
err = dev_set_name(>dev, "vdpa%u", vdev->index);
if (err)
diff --git a/drivers/vdpa/vdpa_sim/vdpa_sim.c 

[PATCH 04/21] vhost-vdpa: switch to use vhost-vdpa specific IOTLB

2020-12-15 Thread Jason Wang
To ease the implementation of per group ASID support for vDPA
device. This patch switches to use a vhost-vdpa specific IOTLB to
avoid the unnecessary refactoring of the vhost core.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 07f92d48c173..9bcc03d4e68b 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -39,6 +39,7 @@ struct vhost_vdpa {
struct vhost_virtqueue *vqs;
struct completion completion;
struct vdpa_device *vdpa;
+   struct vhost_iotlb *iotlb;
struct device dev;
struct cdev cdev;
atomic_t opened;
@@ -526,12 +527,11 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
 
 static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
 {
-   struct vhost_dev *dev = >vdev;
-   struct vhost_iotlb *iotlb = dev->iotlb;
+   struct vhost_iotlb *iotlb = v->iotlb;
 
vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1);
-   kfree(dev->iotlb);
-   dev->iotlb = NULL;
+   kfree(v->iotlb);
+   v->iotlb = NULL;
 }
 
 static int perm_to_iommu_flags(u32 perm)
@@ -745,7 +745,7 @@ static int vhost_vdpa_process_iotlb_msg(struct vhost_dev 
*dev,
struct vhost_vdpa *v = container_of(dev, struct vhost_vdpa, vdev);
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
-   struct vhost_iotlb *iotlb = dev->iotlb;
+   struct vhost_iotlb *iotlb = v->iotlb;
int r = 0;
 
r = vhost_dev_check_owner(dev);
@@ -883,15 +883,15 @@ static int vhost_vdpa_open(struct inode *inode, struct 
file *filep)
vhost_dev_init(dev, vqs, nvqs, 0, 0, 0, false,
   vhost_vdpa_process_iotlb_msg);
 
-   dev->iotlb = vhost_iotlb_alloc(0, 0);
-   if (!dev->iotlb) {
+   v->iotlb = vhost_iotlb_alloc(0, 0);
+   if (!v->iotlb) {
r = -ENOMEM;
goto err_init_iotlb;
}
 
r = vhost_vdpa_alloc_domain(v);
if (r)
-   goto err_init_iotlb;
+   goto err_alloc_domain;
 
vhost_vdpa_set_iova_range(v);
 
@@ -899,6 +899,8 @@ static int vhost_vdpa_open(struct inode *inode, struct file 
*filep)
 
return 0;
 
+err_alloc_domain:
+   vhost_vdpa_iotlb_free(v);
 err_init_iotlb:
vhost_dev_cleanup(>vdev);
kfree(vqs);
-- 
2.25.1



[PATCH 05/21] vdpa: add the missing comment for nvqs in struct vdpa_device

2020-12-15 Thread Jason Wang
Signed-off-by: Jason Wang 
---
 include/linux/vdpa.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/vdpa.h b/include/linux/vdpa.h
index 30bc7a7223bb..8ab8dcde705d 100644
--- a/include/linux/vdpa.h
+++ b/include/linux/vdpa.h
@@ -42,6 +42,7 @@ struct vdpa_vq_state {
  * @config: the configuration ops for this device.
  * @index: device index
  * @features_valid: were features initialized? for legacy guests
+ * @nvqs: the number of virtqueues
  */
 struct vdpa_device {
struct device dev;
-- 
2.25.1



[PATCH 03/21] vhost-vdpa: passing iotlb to IOMMU mapping helpers

2020-12-15 Thread Jason Wang
To prepare for the ASID support for vhost-vdpa, try to pass IOTLB
object to dma helpers. No functional changes, it's just a preparation
for support multiple IOTLBs.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vdpa.c | 41 +++--
 1 file changed, 23 insertions(+), 18 deletions(-)

diff --git a/drivers/vhost/vdpa.c b/drivers/vhost/vdpa.c
index 29ed4173f04e..07f92d48c173 100644
--- a/drivers/vhost/vdpa.c
+++ b/drivers/vhost/vdpa.c
@@ -501,10 +501,11 @@ static long vhost_vdpa_unlocked_ioctl(struct file *filep,
return r;
 }
 
-static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, u64 start, u64 last)
+static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v,
+  struct vhost_iotlb *iotlb,
+  u64 start, u64 last)
 {
struct vhost_dev *dev = >vdev;
-   struct vhost_iotlb *iotlb = dev->iotlb;
struct vhost_iotlb_map *map;
struct page *page;
unsigned long pfn, pinned;
@@ -526,8 +527,9 @@ static void vhost_vdpa_iotlb_unmap(struct vhost_vdpa *v, 
u64 start, u64 last)
 static void vhost_vdpa_iotlb_free(struct vhost_vdpa *v)
 {
struct vhost_dev *dev = >vdev;
+   struct vhost_iotlb *iotlb = dev->iotlb;
 
-   vhost_vdpa_iotlb_unmap(v, 0ULL, 0ULL - 1);
+   vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1);
kfree(dev->iotlb);
dev->iotlb = NULL;
 }
@@ -554,7 +556,7 @@ static int perm_to_iommu_flags(u32 perm)
return flags | IOMMU_CACHE;
 }
 
-static int vhost_vdpa_map(struct vhost_vdpa *v,
+static int vhost_vdpa_map(struct vhost_vdpa *v, struct vhost_iotlb *iotlb,
  u64 iova, u64 size, u64 pa, u32 perm)
 {
struct vhost_dev *dev = >vdev;
@@ -562,7 +564,7 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
const struct vdpa_config_ops *ops = vdpa->config;
int r = 0;
 
-   r = vhost_iotlb_add_range(dev->iotlb, iova, iova + size - 1,
+   r = vhost_iotlb_add_range(iotlb, iova, iova + size - 1,
  pa, perm);
if (r)
return r;
@@ -571,43 +573,44 @@ static int vhost_vdpa_map(struct vhost_vdpa *v,
r = ops->dma_map(vdpa, iova, size, pa, perm);
} else if (ops->set_map) {
if (!v->in_batch)
-   r = ops->set_map(vdpa, dev->iotlb);
+   r = ops->set_map(vdpa, iotlb);
} else {
r = iommu_map(v->domain, iova, pa, size,
  perm_to_iommu_flags(perm));
}
 
if (r)
-   vhost_iotlb_del_range(dev->iotlb, iova, iova + size - 1);
+   vhost_iotlb_del_range(iotlb, iova, iova + size - 1);
else
atomic64_add(size >> PAGE_SHIFT, >mm->pinned_vm);
 
return r;
 }
 
-static void vhost_vdpa_unmap(struct vhost_vdpa *v, u64 iova, u64 size)
+static void vhost_vdpa_unmap(struct vhost_vdpa *v,
+struct vhost_iotlb *iotlb,
+u64 iova, u64 size)
 {
-   struct vhost_dev *dev = >vdev;
struct vdpa_device *vdpa = v->vdpa;
const struct vdpa_config_ops *ops = vdpa->config;
 
-   vhost_vdpa_iotlb_unmap(v, iova, iova + size - 1);
+   vhost_vdpa_iotlb_unmap(v, iotlb, iova, iova + size - 1);
 
if (ops->dma_map) {
ops->dma_unmap(vdpa, iova, size);
} else if (ops->set_map) {
if (!v->in_batch)
-   ops->set_map(vdpa, dev->iotlb);
+   ops->set_map(vdpa, iotlb);
} else {
iommu_unmap(v->domain, iova, size);
}
 }
 
 static int vhost_vdpa_process_iotlb_update(struct vhost_vdpa *v,
+  struct vhost_iotlb *iotlb,
   struct vhost_iotlb_msg *msg)
 {
struct vhost_dev *dev = >vdev;
-   struct vhost_iotlb *iotlb = dev->iotlb;
struct page **page_list;
unsigned long list_size = PAGE_SIZE / sizeof(struct page *);
unsigned int gup_flags = FOLL_LONGTERM;
@@ -676,7 +679,7 @@ static int vhost_vdpa_process_iotlb_update(struct 
vhost_vdpa *v,
if (last_pfn && (this_pfn != last_pfn + 1)) {
/* Pin a contiguous chunk of memory */
csize = (last_pfn - map_pfn + 1) << PAGE_SHIFT;
-   ret = vhost_vdpa_map(v, iova, csize,
+   ret = vhost_vdpa_map(v, iotlb, iova, csize,
 map_pfn << PAGE_SHIFT,
 msg->perm);
if (ret) {
@@ -706,7 +709,8 @@ static int vhost_vdpa_process_iotlb_update(struct 
vhost_vdpa *v,
}
 
/* Pin the rest chunk */
-   ret = vhost_vdpa_map(v, iova, (last_pfn - map_pfn + 1) << PAGE_SHIFT,
+   ret = 

[PATCH 02/21] virtio-vdpa: don't set callback if virtio doesn't need it

2020-12-15 Thread Jason Wang
There's no need for setting callbacks for the driver that doesn't care
about that.

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_vdpa.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/virtio/virtio_vdpa.c b/drivers/virtio/virtio_vdpa.c
index 4a9ddb44b2a7..af6ee677f319 100644
--- a/drivers/virtio/virtio_vdpa.c
+++ b/drivers/virtio/virtio_vdpa.c
@@ -175,7 +175,7 @@ virtio_vdpa_setup_vq(struct virtio_device *vdev, unsigned 
int index,
}
 
/* Setup virtqueue callback */
-   cb.callback = virtio_vdpa_virtqueue_cb;
+   cb.callback = callback ? virtio_vdpa_virtqueue_cb : NULL;
cb.private = info;
ops->set_vq_cb(vdpa, index, );
ops->set_vq_num(vdpa, index, virtqueue_get_vring_size(vq));
-- 
2.25.1



[PATCH 01/21] vhost: move the backend feature bits to vhost_types.h

2020-12-15 Thread Jason Wang
We should store feature bits in vhost_types.h as what has been done
for e.g VHOST_F_LOG_ALL.

Signed-off-by: Jason Wang 
---
 include/uapi/linux/vhost.h   | 5 -
 include/uapi/linux/vhost_types.h | 5 +
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index c998860d7bbc..59c6c0fbaba1 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -89,11 +89,6 @@
 
 /* Set or get vhost backend capability */
 
-/* Use message type V2 */
-#define VHOST_BACKEND_F_IOTLB_MSG_V2 0x1
-/* IOTLB can accept batching hints */
-#define VHOST_BACKEND_F_IOTLB_BATCH  0x2
-
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index f7f6a3a28977..76ee7016c501 100644
--- a/include/uapi/linux/vhost_types.h
+++ b/include/uapi/linux/vhost_types.h
@@ -153,4 +153,9 @@ struct vhost_vdpa_iova_range {
 /* vhost-net should add virtio_net_hdr for RX, and strip for TX packets. */
 #define VHOST_NET_F_VIRTIO_NET_HDR 27
 
+/* Use message type V2 */
+#define VHOST_BACKEND_F_IOTLB_MSG_V2 0x1
+/* IOTLB can accept batching hints */
+#define VHOST_BACKEND_F_IOTLB_BATCH  0x2
+
 #endif
-- 
2.25.1



[PATCH 00/21] Control VQ support in vDPA

2020-12-15 Thread Jason Wang
Hi All:

This series tries to add the support for control virtqueue in vDPA.

Control virtqueue is used by networking device for accepting various
commands from the driver. It's a must to support multiqueue and other
configurations.

When used by vhost-vDPA bus driver for VM, the control virtqueue
should be shadowed via userspace VMM (Qemu) instead of being assigned
directly to Guest. This is because Qemu needs to know the device state
in order to start and stop device correctly (e.g for Live Migration).

This requies to isolate the memory mapping for control virtqueue
presented by vhost-vDPA to prevent guest from accesing it directly.

To achieve this, vDPA introduce two new abstractions:

- address space: identified through address space id (ASID) and a set
 of memory mapping in maintained
- virtqueue group: the minimal set of virtqueues that must share an
 address space

Device needs to advertise the following attributes to vDPA:

- the number of address spaces supported in the device
- the number of virtqueue groups supported in the device
- the mappings from a specific virtqueue to its virtqueue groups

The mappings from virtqueue to virtqueue groups is fixed and defined
by vDPA device driver. E.g:

- For the device that has hardware ASID support, it can simply
  advertise a per virtqueue virtqueue group.
- For the device that does not have hardware ASID support, it can
  simply advertise a single virtqueue group that contains all
  virtqueues. Or if it wants a software emulated control virtqueue, it
  can advertise two virtqueue groups, one is for cvq, another is for
  the rest virtqueues.

vDPA also allow to change the association between virtqueue group and
address space. So in the case of control virtqueue, userspace
VMM(Qemu) may use a dedicated address space for the control virtqueue
group to isolate the memory mapping.

The vhost/vhost-vDPA is also extend for the userspace to:

- query the number of virtqueue groups and address spaces supported by
  the device
- query the virtqueue group for a specific virtqueue
- assocaite a virtqueue group with an address space
- send ASID based IOTLB commands

This will help userspace VMM(Qemu) to detect whether the control vq
could be supported and isolate memory mappings of control virtqueue
from the others.

To demonstrate the usage, vDPA simulator is extended to support
setting MAC address via a emulated control virtqueue.

Please review.

Changes since RFC:

- tweak vhost uAPI documentation
- switch to use device specific IOTLB really in patch 4
- tweak the commit log
- fix that ASID in vhost is claimed to be 32 actually but 16bit
  actually
- fix use after free when using ASID with IOTLB batching requests
- switch to use Stefano's patch for having separated iov
- remove unused "used_as" variable
- fix the iotlb/asid checking in vhost_vdpa_unmap()

Thanks

Jason Wang (20):
  vhost: move the backend feature bits to vhost_types.h
  virtio-vdpa: don't set callback if virtio doesn't need it
  vhost-vdpa: passing iotlb to IOMMU mapping helpers
  vhost-vdpa: switch to use vhost-vdpa specific IOTLB
  vdpa: add the missing comment for nvqs in struct vdpa_device
  vdpa: introduce virtqueue groups
  vdpa: multiple address spaces support
  vdpa: introduce config operations for associating ASID to a virtqueue
group
  vhost_iotlb: split out IOTLB initialization
  vhost: support ASID in IOTLB API
  vhost-vdpa: introduce asid based IOTLB
  vhost-vdpa: introduce uAPI to get the number of virtqueue groups
  vhost-vdpa: introduce uAPI to get the number of address spaces
  vhost-vdpa: uAPI to get virtqueue group id
  vhost-vdpa: introduce uAPI to set group ASID
  vhost-vdpa: support ASID based IOTLB API
  vdpa_sim: advertise VIRTIO_NET_F_MTU
  vdpa_sim: factor out buffer completion logic
  vdpa_sim: filter destination mac address
  vdpasim: control virtqueue support

Stefano Garzarella (1):
  vdpa_sim: split vdpasim_virtqueue's iov field in out_iov and in_iov

 drivers/vdpa/ifcvf/ifcvf_main.c   |   9 +-
 drivers/vdpa/mlx5/net/mlx5_vnet.c |  11 +-
 drivers/vdpa/vdpa.c   |   8 +-
 drivers/vdpa/vdpa_sim/vdpa_sim.c  | 292 --
 drivers/vhost/iotlb.c |  23 ++-
 drivers/vhost/vdpa.c  | 246 -
 drivers/vhost/vhost.c |  23 ++-
 drivers/vhost/vhost.h |   4 +-
 drivers/virtio/virtio_vdpa.c  |   2 +-
 include/linux/vdpa.h  |  42 -
 include/linux/vhost_iotlb.h   |   2 +
 include/uapi/linux/vhost.h|  25 ++-
 include/uapi/linux/vhost_types.h  |  10 +-
 13 files changed, 561 insertions(+), 136 deletions(-)

-- 
2.25.1



Re: [PATCH bpf-next v5 07/11] bpf: Add instructions for atomic_[cmp]xchg

2020-12-15 Thread Yonghong Song




On 12/15/20 4:18 AM, Brendan Jackman wrote:

This adds two atomic opcodes, both of which include the BPF_FETCH
flag. XCHG without the BPF_FETCH flag would naturally encode
atomic_set. This is not supported because it would be of limited
value to userspace (it doesn't imply any barriers). CMPXCHG without
BPF_FETCH woulud be an atomic compare-and-write. We don't have such
an operation in the kernel so it isn't provided to BPF either.

There are two significant design decisions made for the CMPXCHG
instruction:

  - To solve the issue that this operation fundamentally has 3
operands, but we only have two register fields. Therefore the
operand we compare against (the kernel's API calls it 'old') is
hard-coded to be R0. x86 has similar design (and A64 doesn't
have this problem).

A potential alternative might be to encode the other operand's
register number in the immediate field.

  - The kernel's atomic_cmpxchg returns the old value, while the C11
userspace APIs return a boolean indicating the comparison
result. Which should BPF do? A64 returns the old value. x86 returns
the old value in the hard-coded register (and also sets a
flag). That means return-old-value is easier to JIT, so that's
what we use.

Signed-off-by: Brendan Jackman 


Ack with a minor comment below.

Acked-by: Yonghong Song 


---
  arch/x86/net/bpf_jit_comp.c|  8 
  include/linux/filter.h |  2 ++
  include/uapi/linux/bpf.h   |  4 +++-
  kernel/bpf/core.c  | 20 
  kernel/bpf/disasm.c| 15 +++
  kernel/bpf/verifier.c  | 19 +--
  tools/include/linux/filter.h   |  2 ++
  tools/include/uapi/linux/bpf.h |  4 +++-
  8 files changed, 70 insertions(+), 4 deletions(-)

diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
index eea7d8b0bb12..308241187582 100644
--- a/arch/x86/net/bpf_jit_comp.c
+++ b/arch/x86/net/bpf_jit_comp.c
@@ -815,6 +815,14 @@ static int emit_atomic(u8 **pprog, u8 atomic_op,
/* src_reg = atomic_fetch_add(dst_reg + off, src_reg); */
EMIT2(0x0F, 0xC1);
break;
+   case BPF_XCHG:
+   /* src_reg = atomic_xchg(dst_reg + off, src_reg); */
+   EMIT1(0x87);
+   break;
+   case BPF_CMPXCHG:
+   /* r0 = atomic_cmpxchg(dst_reg + off, r0, src_reg); */
+   EMIT2(0x0F, 0xB1);
+   break;
default:
pr_err("bpf_jit: unknown atomic opcode %02x\n", atomic_op);
return -EFAULT;
diff --git a/include/linux/filter.h b/include/linux/filter.h
index c3e87a63e0b8..16e0ba5e8937 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -265,6 +265,8 @@ static inline bool insn_is_zext(const struct bpf_insn *insn)
   *
   *   BPF_ADD  *(uint *) (dst_reg + off16) += src_reg
   *   BPF_ADD | BPF_FETCH  src_reg = atomic_fetch_add(dst_reg + off16, 
src_reg);
+ *   BPF_XCHG src_reg = atomic_xchg(dst_reg + off16, src_reg)
+ *   BPF_CMPXCHG  r0 = atomic_cmpxchg(dst_reg + off16, r0, src_reg)
   */
  
  #define BPF_ATOMIC_OP(SIZE, OP, DST, SRC, OFF)			\

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 760ae333a5ed..538b95472c8f 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -45,7 +45,9 @@
  #define BPF_EXIT  0x90/* function return */
  
  /* atomic op type fields (stored in immediate) */

-#define BPF_FETCH  0x01/* fetch previous value into src reg */
+#define BPF_XCHG   (0xe0 | BPF_FETCH)  /* atomic exchange */
+#define BPF_CMPXCHG(0xf0 | BPF_FETCH)  /* atomic compare-and-write */
+#define BPF_FETCH  0x01/* not an opcode on its own, used to build 
others */


Although the above code works fine, I would suggest to put
BPF_FETCH definition before BPF_XCHG and BPF_CMPXCHG, which
makes more sense intuitively.

  
  /* Register numbers */

  enum {
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c

[...]   \

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index 760ae333a5ed..538b95472c8f 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -45,7 +45,9 @@
  #define BPF_EXIT  0x90/* function return */
  
  /* atomic op type fields (stored in immediate) */

-#define BPF_FETCH  0x01/* fetch previous value into src reg */
+#define BPF_XCHG   (0xe0 | BPF_FETCH)  /* atomic exchange */
+#define BPF_CMPXCHG(0xf0 | BPF_FETCH)  /* atomic compare-and-write */
+#define BPF_FETCH  0x01/* not an opcode on its own, used to build 
others */


same here.

  
  /* Register numbers */

  enum {



[PATCH 1/2] hid: intel-ish-hid: ipc: finish power flow for EHL OOB

2020-12-15 Thread Zhang Lixu
The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings. When
enabled, the ISH device gets PME wake capability. To enable PME wakeup,
driver also needs to enable ACPI GPE bit.

Once wakeup, BIOS will clear the wakeup bit to identify wakeup is
successful. So driver need to re-enable it in resume function to
keep the next wakeup capability.

Since this feature is only present on EHL, we use EHL PCI device id to
enable this feature.

Co-developed-by: Najumon Ba 
Signed-off-by: Najumon Ba 
Signed-off-by: Even Xu 
Signed-off-by: Zhang Lixu 
---
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 48 +
 1 file changed, 48 insertions(+)

diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c 
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index c6d48a8648b7..c9c5488e44cb 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -5,6 +5,7 @@
  * Copyright (c) 2014-2016, Intel Corporation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -111,6 +112,42 @@ static inline bool ish_should_leave_d0i3(struct pci_dev 
*pdev)
return !pm_resume_via_firmware() || pdev->device == CHV_DEVICE_ID;
 }
 
+static int enable_gpe(struct device *dev)
+{
+#ifdef CONFIG_ACPI
+   acpi_status acpi_sts;
+   struct acpi_device *adev;
+   struct acpi_device_wakeup *wakeup;
+
+   adev = ACPI_COMPANION(dev);
+   if (!adev) {
+   dev_err(dev, "get acpi handle failed\n");
+   return -ENODEV;
+   }
+   wakeup = >wakeup;
+
+   acpi_sts = acpi_enable_gpe(wakeup->gpe_device, wakeup->gpe_number);
+   if (ACPI_FAILURE(acpi_sts)) {
+   dev_err(dev, "enable ose_gpe failed\n");
+   return -EIO;
+   }
+
+   return 0;
+#else
+   return -ENODEV;
+#endif
+}
+
+static void enable_pme_wake(struct pci_dev *pdev)
+{
+   if ((pci_pme_capable(pdev, PCI_D0) ||
+pci_pme_capable(pdev, PCI_D3hot) ||
+pci_pme_capable(pdev, PCI_D3cold)) && !enable_gpe(>dev)) {
+   pci_pme_active(pdev, true);
+   dev_dbg(>dev, "ish ipc driver pme wake enabled\n");
+   }
+}
+
 /**
  * ish_probe() - PCI driver probe callback
  * @pdev:  pci device
@@ -179,6 +216,10 @@ static int ish_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
init_waitqueue_head(>suspend_wait);
init_waitqueue_head(>resume_wait);
 
+   /* Enable PME for EHL */
+   if (pdev->device == EHL_Ax_DEVICE_ID)
+   enable_pme_wake(pdev);
+
ret = ish_init(ishtp);
if (ret)
return ret;
@@ -317,6 +358,13 @@ static int __maybe_unused ish_resume(struct device *device)
struct pci_dev *pdev = to_pci_dev(device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
 
+   /* add this to finish power flow for EHL */
+   if (dev->pdev->device == EHL_Ax_DEVICE_ID) {
+   pci_set_power_state(pdev, PCI_D0);
+   enable_pme_wake(pdev);
+   dev_dbg(dev->devc, "set power state to D0 for ehl\n");
+   }
+
ish_resume_device = device;
dev->resume_flag = 1;
 
-- 
2.25.1



[PATCH 2/2] hid: intel-ish-hid: ipc: Address EHL Sx resume issues

2020-12-15 Thread Zhang Lixu
When OOB is disabled, FW will be power gated when system is in S3/S4/S5
which is the same behavior with legacy ISH FW.
When OOB is enabled, FW will always power on which is totally different
comparing to legacy ISH FW.

So NO_D3 flag is not enough to check FW's status after resume.
Here we can use IPC FW status register to check host link status.
If it is false, it means FW get reset after power gated, need go through
the whole initialization flow; If it is true, it means FW is alive, just
set host ready bit to let fw know host is up.

Co-developed-by: Wei Jiang 
Signed-off-by: Wei Jiang 
Signed-off-by: Even Xu 
Signed-off-by: Zhang Lixu 
---
 drivers/hid/intel-ish-hid/ipc/hw-ish.h  |  1 +
 drivers/hid/intel-ish-hid/ipc/ipc.c | 27 +
 drivers/hid/intel-ish-hid/ipc/pci-ish.c |  6 +-
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/hid/intel-ish-hid/ipc/hw-ish.h 
b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
index 1fb294ca463e..111ad259ba74 100644
--- a/drivers/hid/intel-ish-hid/ipc/hw-ish.h
+++ b/drivers/hid/intel-ish-hid/ipc/hw-ish.h
@@ -81,5 +81,6 @@ struct ishtp_device *ish_dev_init(struct pci_dev *pdev);
 int ish_hw_start(struct ishtp_device *dev);
 void ish_device_disable(struct ishtp_device *dev);
 int ish_disable_dma(struct ishtp_device *dev);
+void ish_set_host_ready(struct ishtp_device *dev);
 
 #endif /* _ISHTP_HW_ISH_H_ */
diff --git a/drivers/hid/intel-ish-hid/ipc/ipc.c 
b/drivers/hid/intel-ish-hid/ipc/ipc.c
index a45ac7fa417b..47bbeb8b492b 100644
--- a/drivers/hid/intel-ish-hid/ipc/ipc.c
+++ b/drivers/hid/intel-ish-hid/ipc/ipc.c
@@ -193,6 +193,33 @@ static void ish_clr_host_rdy(struct ishtp_device *dev)
ish_reg_write(dev, IPC_REG_HOST_COMM, host_status);
 }
 
+static bool ish_chk_host_rdy(struct ishtp_device *dev)
+{
+   uint32_t host_status = ish_reg_read(dev, IPC_REG_HOST_COMM);
+
+   return (host_status & IPC_HOSTCOMM_READY_BIT);
+}
+
+/**
+ * ish_set_host_ready() - reconfig ipc host registers
+ * @dev: ishtp device pointer
+ *
+ * Set host to ready state
+ * This API is called in some case:
+ *fw is still on, but ipc is powered down.
+ *such as OOB case.
+ *
+ * Return: 0 for success else error fault code
+ */
+void ish_set_host_ready(struct ishtp_device *dev)
+{
+   if (ish_chk_host_rdy(dev))
+   return;
+
+   ish_set_host_rdy(dev);
+   set_host_ready(dev);
+}
+
 /**
  * _ishtp_read_hdr() - Read message header
  * @dev: ISHTP device pointer
diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c 
b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
index c9c5488e44cb..8cb40696984a 100644
--- a/drivers/hid/intel-ish-hid/ipc/pci-ish.c
+++ b/drivers/hid/intel-ish-hid/ipc/pci-ish.c
@@ -259,11 +259,15 @@ static void __maybe_unused ish_resume_handler(struct 
work_struct *work)
 {
struct pci_dev *pdev = to_pci_dev(ish_resume_device);
struct ishtp_device *dev = pci_get_drvdata(pdev);
+   uint32_t fwsts = dev->ops->get_fw_status(dev);
int ret;
 
-   if (ish_should_leave_d0i3(pdev) && !dev->suspend_flag) {
+   if (ish_should_leave_d0i3(pdev) && !dev->suspend_flag
+   && IPC_IS_ISH_ILUP(fwsts)) {
disable_irq_wake(pdev->irq);
 
+   ish_set_host_ready(dev);
+
ishtp_send_resume(dev);
 
/* Waiting to get resume response */
-- 
2.25.1



[PATCH 0/2] hid: intel-ish-hid: ipc: enable OOB support for EHL

2020-12-15 Thread Zhang Lixu
The EHL (Elkhart Lake) based platforms provide a OOB (Out of band)
service, which allows wakup device when the system is in S5 (Soft-Off
state). This OOB service can be enabled/disabled from BIOS settings.

These two patches is to enable this feature for EHL platform.

We have tested these patches on both ISH platforms and EHL platforms,
it works fine.

Zhang Lixu (2):
  hid: intel-ish-hid: ipc: finish power flow for EHL OOB
  hid: intel-ish-hid: ipc: Address EHL Sx resume issues

 drivers/hid/intel-ish-hid/ipc/hw-ish.h  |  1 +
 drivers/hid/intel-ish-hid/ipc/ipc.c | 27 +
 drivers/hid/intel-ish-hid/ipc/pci-ish.c | 54 -
 3 files changed, 81 insertions(+), 1 deletion(-)

-- 
2.25.1



Re: [PATCH RFC 0/3] Implement guest time scaling in RISC-V KVM

2020-12-15 Thread Anup Patel
On Thu, Dec 3, 2020 at 5:51 PM Yifei Jiang  wrote:
>
> This series implements guest time scaling based on RDTIME instruction
> emulation so that we can allow migrating Guest/VM across Hosts with
> different time frequency.
>
> Why not through para-virt. From arm's experience[1], para-virt implementation
> doesn't really solve the problem for the following two main reasons:
> - RDTIME not only be used in linux, but also in firmware and userspace.
> - It is difficult to be compatible with nested virtualization.

I think this approach is rather incomplete. Also, I don't see how para-virt
time scaling will be difficult for nested virtualization.

If trap-n-emulate TIME CSR for Guest Linux then it will have significant
performance impact of systems where TIME CSR is implemented in HW.

Best approach will be to have VDSO-style para-virt time-scale SBI calls
(similar to what KVM x86 does). If the Guest software (Linux/Bootloader)
does not enable para-virt time-scaling then we trap-n-emulate TIME CSR
(this series).

Please propose VDSO-style para-virt time-scale SBI call and expand this
this series to provide both:
1. VDSO-style para-virt time-scaling
2. Trap-n-emulation of TIME CSR when #1 is disabled

Regards,
Anup

>
> [1] https://lore.kernel.org/patchwork/cover/1288153/
>
> Yifei Jiang (3):
>   RISC-V: KVM: Change the method of calculating cycles to nanoseconds
>   RISC-V: KVM: Support dynamic time frequency from userspace
>   RISC-V: KVM: Implement guest time scaling
>
>  arch/riscv/include/asm/csr.h|  3 ++
>  arch/riscv/include/asm/kvm_vcpu_timer.h | 13 +--
>  arch/riscv/kvm/vcpu_exit.c  | 35 +
>  arch/riscv/kvm/vcpu_timer.c | 51 ++---
>  4 files changed, 93 insertions(+), 9 deletions(-)
>
> --
> 2.19.1
>
>
> --
> kvm-riscv mailing list
> kvm-ri...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kvm-riscv


RE: [PATCH v2 03/10] regulator: bd9571mwv: rid of using struct bd9571mwv

2020-12-15 Thread Yoshihiro Shimoda
Hi Matti-san,

> From: Vaittinen, Matti, Sent: Wednesday, December 16, 2020 3:00 PM
> On Wed, 2020-12-16 at 02:13 +, Yoshihiro Shimoda wrote:
> > Hi Geert-san, Matti-san,
> >
> > > From: Geert Uytterhoeven, Sent: Wednesday, December 16, 2020 1:13
> > > AM
> > > On Tue, Dec 15, 2020 at 5:02 PM Geert Uytterhoeven <
> > > ge...@linux-m68k.org> wrote:
> > > > On Fri, Dec 11, 2020 at 3:03 PM Vaittinen, Matti
> > > >  wrote:
> > > > > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> > 
> > > > > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > > > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > > > > @@ -17,7 +17,7 @@
> > > > > >  #include 
> > > > > >
> > > > > >  struct bd9571mwv_reg {
> > > > > > - struct bd9571mwv *bd;
> > > > > > + struct regmap *regmap;
> > > > >
> > > > > As a 'nit':
> > > > > I might consider adding the dev pointer here to avoid extra
> > > > > argument
> > > > > with all the bkup_mode functions below. (just pass this struct
> > > > > and
> > > > > mode). But that's only my preference - feel free to ignore this
> > > > > comment
> > > > > if patch is Ok to Mark, Marek & Others :)
> > > >
> > > > Struct regmap already contains a struct device pointer, but
> > > > that's internal
> > > > to regmap.
> > > >
> > > > Perhaps adding a regmap_device() helper to retrieve the device
> > > > pointer
> > > > might be worthwhile?
> > >
> > > -EEXISTS ;-)
> > >
> > > struct device *regmap_get_device(struct regmap *map)
> >
> > Thank you for finding this. I'll fix this patch.
> 
> Just a small reminder that this device is probably the MFD device, not
> the device created for regulator driver. (Regmap is created for MFD).
> For prints this only means we're issuing prints as if MFD device
> generated them, right? I'm not sure it is the best approach - but I'll
> leave this to Mark & others to judge :)

Thank you for the comment. You're correct. regmap_get_device() is
the MFD device. Also, original code had used the MFD device as
"dev_err(bd->dev, ...)". So, printk behavior is the same as before :)

Best regards,
Yoshihiro Shimoda



Re: [PATCH] Documentation: kunit: include example of a parameterized test

2020-12-15 Thread David Gow
On Wed, Dec 16, 2020 at 8:23 AM Daniel Latypov  wrote:
>
> Commit fadb08e7c750 ("kunit: Support for Parameterized Testing")
> introduced support but lacks documentation for how to use it.
>
> This patch builds on commit 1f0e943df68a ("Documentation: kunit: provide
> guidance for testing many inputs") to show a minimal example of the new
> feature.
>
> Signed-off-by: Daniel Latypov 
> ---

This looks good to me. Thanks!

Reviewed-by: David Gow 

-- David


smime.p7s
Description: S/MIME Cryptographic Signature


Re: [PATCH 1/5] modpost: rename merror() to error()

2020-12-15 Thread Masahiro Yamada
On Tue, Dec 1, 2020 at 7:34 PM Masahiro Yamada  wrote:
>
> The log function names, warn(), merror(), fatal() are inconsistent.
>
> Commit 2a11665945d5 ("kbuild: distinguish between errors and warnings
> in modpost") intentionally chose merror() to avoid the conflict with
> the library function error(). See man page of error(3).
>
> But, we are already causing the conflict with warn() because it is also
> a library function. See man page of warn(3). err() would be a problem
> for the same reason.
>
> The common technique to work around name conflicts is to use macros.
>
> #define error __error
> void __error(const char *fmt, ...)
> {
> 
> }
>
> #define warn __warn
> void __warn(const char *fmt, ...)
> {
> 
> }
>
> In this way, we can implement our own warn() and error(), still we can
> include  and  with no problem.
>
> And, commit 93c95e526a4e ("modpost: rework and consolidate logging
> interface") already did that.
>
> Since the log functions are all macros, we can use error() without
> causing "conflicting types" errors.
>
> Signed-off-by: Masahiro Yamada 

This series, applied to linux-kbuild.


> ---
>
>  scripts/mod/modpost.c | 10 +-
>  scripts/mod/modpost.h |  2 +-
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index f882ce0d9327..337f6ca4bda3 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -403,8 +403,8 @@ static void sym_update_namespace(const char *symname, 
> const char *namespace)
>  * actually an assertion.
>  */
> if (!s) {
> -   merror("Could not update namespace(%s) for symbol %s\n",
> -  namespace, symname);
> +   error("Could not update namespace(%s) for symbol %s\n",
> + namespace, symname);
> return;
> }
>
> @@ -2226,7 +2226,7 @@ static int check_modname_len(struct module *mod)
> else
> mod_name++;
> if (strlen(mod_name) >= MODULE_NAME_LEN) {
> -   merror("module name is too long [%s.ko]\n", mod->name);
> +   error("module name is too long [%s.ko]\n", mod->name);
> return 1;
> }
>
> @@ -2319,8 +2319,8 @@ static int add_versions(struct buffer *b, struct module 
> *mod)
> continue;
> }
> if (strlen(s->name) >= MODULE_NAME_LEN) {
> -   merror("too long symbol \"%s\" [%s.ko]\n",
> -  s->name, mod->name);
> +   error("too long symbol \"%s\" [%s.ko]\n",
> + s->name, mod->name);
> err = 1;
> break;
> }
> diff --git a/scripts/mod/modpost.h b/scripts/mod/modpost.h
> index 3aa052722233..f453504ad4df 100644
> --- a/scripts/mod/modpost.h
> +++ b/scripts/mod/modpost.h
> @@ -202,5 +202,5 @@ enum loglevel {
>  void modpost_log(enum loglevel loglevel, const char *fmt, ...);
>
>  #define warn(fmt, args...) modpost_log(LOG_WARN, fmt, ##args)
> -#define merror(fmt, args...)   modpost_log(LOG_ERROR, fmt, ##args)
> +#define error(fmt, args...)modpost_log(LOG_ERROR, fmt, ##args)
>  #define fatal(fmt, args...)modpost_log(LOG_FATAL, fmt, ##args)
> --
> 2.27.0
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH 04/25] dt-bindings: net: dwmac: Refactor snps,*-config properties

2020-12-15 Thread Serge Semin
On Tue, Dec 15, 2020 at 08:08:35AM -0600, Rob Herring wrote:
> On Tue, Dec 15, 2020 at 2:54 AM Serge Semin
>  wrote:
> >
> > Hello Rob,
> >
> > On Mon, Dec 14, 2020 at 08:30:06AM -0600, Rob Herring wrote:
> > > On Mon, Dec 14, 2020 at 12:15:54PM +0300, Serge Semin wrote:
> > > > Currently the "snps,axi-config", "snps,mtl-rx-config" and
> > > > "snps,mtl-tx-config" properties are declared as a single phandle 
> > > > reference
> > > > to a node with corresponding parameters defined. That's not good for
> > > > several reasons. First of all scattering around a device tree some
> > > > particular device-specific configs with no visual relation to that 
> > > > device
> > > > isn't suitable from maintainability point of view. That leads to a
> > > > disturbed representation of the actual device tree mixing actual device
> > > > nodes and some vendor-specific configs. Secondly using the same configs
> > > > set for several device nodes doesn't represent well the devices 
> > > > structure,
> > > > since the interfaces these configs describe in hardware belong to
> > > > different devices and may actually differ. In the later case having the
> > > > configs node separated from the corresponding device nodes gets to be
> > > > even unjustified.
> > > >
> > > > So instead of having a separate DW *MAC configs nodes we suggest to
> > > > define them as sub-nodes of the device nodes, which interfaces they
> > > > actually describe. By doing so we'll make the DW *MAC nodes visually
> > > > correct describing all the aspects of the IP-core configuration. Thus
> > > > we'll be able to describe the configs sub-nodes bindings right in the
> > > > snps,dwmac.yaml file.
> > > >
> > > > Note the former "snps,axi-config", "snps,mtl-rx-config" and
> > > > "snps,mtl-tx-config" bindings have been marked as deprecated.
> > > >
> > > > Signed-off-by: Serge Semin 
> > > >
> > > > ---
> > > >
> > > > Note the current DT schema tool requires the vendor-specific properties 
> > > > to be
> > > > defined in accordance with the schema: 
> > > > dtschema/meta-schemas/vendor-props.yaml
> > > > It means the property can be;
> > > > - boolean,
> > > > - string,
> > > > - defined with $ref and additional constraints,
> > > > - defined with allOf: [ $ref ] and additional constraints.
> > > >
> > > > The modification provided by this commit needs to extend that 
> > > > definition to
> > > > make the DT schema tool correctly parse this schema. That is we need to 
> > > > let
> > > > the vendors-specific properties to also accept the oneOf-based combined
> > > > sub-schema. Like this:
> > > >
> > > > --- a/dtschema/meta-schemas/vendor-props.yaml
> > > > +++ b/dtschema/meta-schemas/vendor-props.yaml
> > > > @@ -48,15 +48,24 @@
> > > >- properties:   # A property with a type and additional 
> > > > constraints
> > > >$ref:
> > > >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > > -  allOf:
> > > > -items:
> > > > -  - properties:
> > > > +
> > > > +if:
> > > > +  not:
> > > > +required:
> > > > +  - $ref
> > > > +then:
> > > > +  patternProperties:
> > > > +"^(all|one)Of$":
> > > > +  contains:
> > > > +properties:
> > > >$ref:
> > > >  pattern: "types.yaml#[\/]{0,1}definitions\/.*"
> > > >  required:
> > > >- $ref
> > > > -oneOf:
> > > > +
> > > > +anyOf:
> > > >- required: [ $ref ]
> > > >- required: [ allOf ]
> > > > +  - required: [ oneOf ]
> > > >
> > > >  ...
> > > > ---
> > > >  .../devicetree/bindings/net/snps,dwmac.yaml   | 380 +-
> > > >  1 file changed, 288 insertions(+), 92 deletions(-)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> > > > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > > index 0dd543c6c08e..44aa88151cba 100644
> > > > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > > > @@ -150,69 +150,251 @@ properties:
> > > >in a different mode than the PHY in order to function.
> > > >
> > > >snps,axi-config:
> > > > -$ref: /schemas/types.yaml#definitions/phandle
> > > > -description:
> > > > -  AXI BUS Mode parameters. Phandle to a node that can contain the
> > > > -  following properties
> > > > -* snps,lpi_en, enable Low Power Interface
> > > > -* snps,xit_frm, unlock on WoL
> > > > -* snps,wr_osr_lmt, max write outstanding req. limit
> > > > -* snps,rd_osr_lmt, max read outstanding req. limit
> > > > -* snps,kbbe, do not cross 1KiB boundary.
> > > > -* snps,blen, this is a vector of supported burst length.
> > > > -* snps,fb, fixed-burst
> > > > -* snps,mb, mixed-burst
> > > > -* snps,rb, 

Re: [PATCH v2] modpost: turn static exports into error

2020-12-15 Thread Masahiro Yamada
On Wed, Dec 2, 2020 at 1:52 AM Quentin Perret  wrote:
>
> Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
> Modpost currently reports that as a warning, but clearly this is not a
> pattern we should allow, and all in-tree occurences should have been
> fixed by now. So, promote the warn() message to error() to make sure
> this never happens again.
>
> Acked-by: Greg Kroah-Hartman 
> Reviewed-by: Matthias Maennich 
> Signed-off-by: Quentin Perret 
>
> ---
> v2: now depends on 20201201103418.675850-2-masahi...@kernel.org

Applied to linux-kbuild. Thanks.


> ---
>  scripts/mod/modpost.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
> index 43e00867623a..5562526c8c32 100644
> --- a/scripts/mod/modpost.c
> +++ b/scripts/mod/modpost.c
> @@ -2648,9 +2648,9 @@ int main(int argc, char **argv)
>
> for (s = symbolhash[n]; s; s = s->next) {
> if (s->is_static)
> -   warn("\"%s\" [%s] is a static %s\n",
> -s->name, s->module->name,
> -export_str(s->export));
> +   error("\"%s\" [%s] is a static %s\n",
> + s->name, s->module->name,
> + export_str(s->export));
> }
> }
>
> --
> 2.29.2.454.gaff20da3a2-goog
>


-- 
Best Regards
Masahiro Yamada


Re: [PATCH] kbuild: avoid split lines in .mod files

2020-12-15 Thread Masahiro Yamada
On Fri, Dec 4, 2020 at 3:46 AM 'Sami Tolvanen' via Clang Built Linux
 wrote:
>
> Hi Masahiro,
>
> On Thu, Dec 3, 2020 at 9:56 AM Masahiro Yamada  wrote:
> >
> > "xargs echo" is not a safe way to remove line breaks because the input
> > may exceed the command line limit and xargs may break it up into
> > multiple invocations of echo. This should never happen because
> > scripts/gen_autoksyms.sh expects all undefined symbols are placed in
> > the second line of .mod files.
> >
> > One possible way is to replace "xargs echo" with
> > "sed ':x;N;$!bx;s/\n/ /g'" or something, but I rewrote the code by
> > using awk because it is more readable.
> >
> > This issue was reported by Sami Tolvanen; in his Clang LTO patch set,
> > $(multi-used-m) is no longer an ELF object, but a thin archive that
> > contains LLVM bitcode files. llvm-nm prints out symbols for each
> > archive member separately, which results a lot of dupications, in some
> > places, beyond the system-defined limit.
> >
> > This problem must be fixed irrespective of LTO, and we must ensure
> > zero possibility of having this issue.
> >
> > Link: https://lkml.org/lkml/2020/12/1/1658
> > Reported-by: Sami Tolvanen 
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  scripts/Makefile.build | 12 
> >  1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > index ae647379b579..4c058f12dd73 100644
> > --- a/scripts/Makefile.build
> > +++ b/scripts/Makefile.build
> > @@ -252,6 +252,9 @@ objtool_dep = $(objtool_obj)
> > \
> >  ifdef CONFIG_TRIM_UNUSED_KSYMS
> >  cmd_gen_ksymdeps = \
> > $(CONFIG_SHELL) $(srctree)/scripts/gen_ksymdeps.sh $@ >> 
> > $(dot-target).cmd
> > +
> > +# List module undefined symbols
> > +undefined_syms = $(NM) $< | $(AWK) '$$1 == "U" { printf("%s%s", x++ ? " " 
> > : "", $$2) }';
> >  endif
> >
> >  define rule_cc_o_c
> > @@ -271,13 +274,6 @@ define rule_as_o_S
> > $(call cmd,modversions_S)
> >  endef
> >
> > -# List module undefined symbols (or empty line if not enabled)
> > -ifdef CONFIG_TRIM_UNUSED_KSYMS
> > -cmd_undef_syms = $(NM) $< | sed -n 's/^  *U //p' | xargs echo
> > -else
> > -cmd_undef_syms = echo
> > -endif
> > -
> >  # Built-in and composite module parts
> >  $(obj)/%.o: $(src)/%.c $(recordmcount_source) $(objtool_dep) FORCE
> > $(call if_changed_rule,cc_o_c)
> > @@ -285,7 +281,7 @@ $(obj)/%.o: $(src)/%.c $(recordmcount_source) 
> > $(objtool_dep) FORCE
> >
> >  cmd_mod = { \
> > echo $(if $($*-objs)$($*-y)$($*-m), $(addprefix $(obj)/, $($*-objs) 
> > $($*-y) $($*-m)), $(@:.mod=.o)); \
> > -   $(cmd_undef_syms); \
> > +   $(undefined_syms) echo; \
> > } > $@
> >
> >  $(obj)/%.mod: $(obj)/%.o FORCE
>
> Thanks for the patch! I confirmed that this works with llvm-nm and
> bitcode files, but it does still produce plenty of duplicates,

Actually, the duplication does not matter
because scripts/gen_autoksyms.sh line 46
calls 'sort -u' anyway.
Only the problem is we have bigger .mod files, though.

We do not have a good reason
to move 'sort -u' for now.




> even
> though they now stay on one line. I'm not sure if the readability of
> the .mod file matters though. Please feel free to add:
>
> Reviewed-by: Sami Tolvanen 
>
> Sami
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Clang Built Linux" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to clang-built-linux+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/clang-built-linux/CABCJKufyBcN-foh0kj5kUsn-wiZMJ_a8ZjB72jaTmN2GEVzVNA%40mail.gmail.com.



-- 
Best Regards
Masahiro Yamada


Re: [PATCH] kbuild: add extra-y to targets-for-modules

2020-12-15 Thread Masahiro Yamada
On Tue, Dec 8, 2020 at 11:31 PM Artem Savkov  wrote:
>
> On Tue, Dec 08, 2020 at 05:20:35PM +0800, WANG Chao wrote:
> > Sorry for the late reply.
> >
> > On 11/25/20 at 10:42P, Masahiro Yamada wrote:
> > > On Tue, Nov 24, 2020 at 12:05 AM WANG Chao  wrote:
> > > >
> > > > On 11/23/20 at 02:23P, Masahiro Yamada wrote:
> > > > > On Tue, Nov 3, 2020 at 3:23 PM WANG Chao  wrote:
> > > > > >
> > > > > > extra-y target doesn't build for 'make M=...' since commit 
> > > > > > 6212804f2d78
> > > > > > ("kbuild: do not create built-in objects for external module 
> > > > > > builds").
> > > > > >
> > > > > > This especially breaks kpatch, which is using 'extra-y := 
> > > > > > kpatch.lds'
> > > > > > and 'make M=...' to build livepatch patch module.
> > > > > >
> > > > > > Add extra-y to targets-for-modules so that such kind of build works
> > > > > > properly.
> > > > > >
> > > > > > Signed-off-by: WANG Chao 
> > > > > > ---
> > > > > >  scripts/Makefile.build | 2 +-
> > > > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> > > > > > index ae647379b579..0113a042d643 100644
> > > > > > --- a/scripts/Makefile.build
> > > > > > +++ b/scripts/Makefile.build
> > > > > > @@ -86,7 +86,7 @@ ifdef need-builtin
> > > > > >  targets-for-builtin += $(obj)/built-in.a
> > > > > >  endif
> > > > > >
> > > > > > -targets-for-modules := $(patsubst %.o, %.mod, $(filter %.o, 
> > > > > > $(obj-m)))
> > > > > > +targets-for-modules := $(extra-y) $(patsubst %.o, %.mod, $(filter 
> > > > > > %.o, $(obj-m)))
> > > > > >
> > > > > >  ifdef need-modorder
> > > > > >  targets-for-modules += $(obj)/modules.order
> > > > > > --
> > > > > > 2.29.1
> > > > > >
> > > > >
> > > > > NACK.
> > > > >
> > > > > Please fix your Makefile.
> > > > >
> > > > > Hint:
> > > > > https://patchwork.kernel.org/project/linux-kbuild/patch/20201123045403.63402-6-masahi...@kernel.org/
> > > > >
> > > > >
> > > > > Probably what you should use is 'targets'.
> > > >
> > > > I tried with 'targets' and 'always-y'. Both doesn't work for me.
> > > >
> > > > I narraw it down to the following example:
> > > >
> > > > cat > Makefile << _EOF_
> > > > obj-m += foo.o
> > > >
> > > > ldflags-y += -T $(src)/kpatch.lds
> > > > always-y += kpatch.lds
> > > >
> > > > foo-objs += bar.o
> > > >
> > > > all:
> > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD)
> > > > clean:
> > > > make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
> > > > _EOF_
> > > >
> > > > Take a look into scripts/Makefile.build:488:
> > > >
> > > > __build: $(if $(KBUILD_BUILTIN), $(targets-for-builtin)) \
> > > >  $(if $(KBUILD_MODULES), $(targets-for-modules)) \
> > > >  $(subdir-ym) $(always-y)
> > > > @:
> > > >
> > > > 'always-y' is built after 'targets-for-modules'. This makes
> > > > 'targets-for-modules' fails because kpatch.lds isn't there.
> > >
> > >
> > > Heh, you rely on the targets built from left to right,
> > > and you have never thought Make supports the parallel option -j.
> >
> > You're right. I missed that.
> >
> > >
> > >
> > > You need to specify the dependency if you expect objects
> > > are built in the particular order.
> > >
> > > However, in this case, using ldflags-y looks wrong
> > > in the first place.
> > >
> > > The linker script is used when combining the object
> > > as well as the final link of *.ko
>
> We want linker script to be used on both those steps, otherwise modpost
> fails.


In that case, does the following work?
(untested)



diff --git a/kmod/patch/Makefile b/kmod/patch/Makefile
index e017b17..02d4c66 100644
--- a/kmod/patch/Makefile
+++ b/kmod/patch/Makefile
@@ -12,7 +12,9 @@ endif

 obj-m += $(KPATCH_NAME).o
 ldflags-y += -T $(src)/kpatch.lds
-extra-y := kpatch.lds
+targets += kpatch.lds
+
+$(obj)/$(KPATCH_NAME).o: $(obj)/kpatch.lds

 $(KPATCH_NAME)-objs += patch-hook.o output.o





>
> It looks like the right thing to do here is leave ldflags-y in, get rid
> of always-y/extra-y altogether and specify our linker script as a
> dependency for the object.
>
> > I don't have a clean fix to kpatch right now.
> >
> > I'm looping kpatch forks in. They're also looking at this right now:
> >
> > https://github.com/dynup/kpatch/pull/1149
> >
> > Thanks
> > WANG Chao
> >
> > >
> > >
> > > > For 'targets', in case of OOT, does not seem to be useful.
> > > >
> > > > What change do you suggest to make to fix this kind of Makefile?
> > > >
> > > > Thanks,
> > > > WANG Chao
> > >
> > >
> > >
> > > --
> > > Best Regards
> > > Masahiro Yamada
> > >
> >
>
> --
> Regards,
>   Artem Savkov



-- 
Best Regards
Masahiro Yamada


Re: [PATCH 1/2] venus: venc: update output format based on capture format.

2020-12-15 Thread dikshita

Hi All,

Kindly ignore this patch.
https://patchwork.linuxtv.org/project/linux-media/list/?series=3790 
replaces this.


Thanks,
Dikshita

On 2020-09-24 23:01, Dikshita Agarwal wrote:

update output format parameters when s_fmt is called on
capture port as recommended in encoder spec.

Signed-off-by: Dikshita Agarwal 
---
 drivers/media/platform/qcom/venus/venc.c | 28 
+++-

 1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/media/platform/qcom/venus/venc.c
b/drivers/media/platform/qcom/venus/venc.c
index c591d00..7d2aaa8 100644
--- a/drivers/media/platform/qcom/venus/venc.c
+++ b/drivers/media/platform/qcom/venus/venc.c
@@ -382,31 +382,33 @@ static int venc_s_fmt(struct file *file, void
*fh, struct v4l2_format *f)

memset(, 0, sizeof(format));

-   format.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
-   format.fmt.pix_mp.pixelformat = pixfmt_out;
+   format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+   format.fmt.pix_mp.pixelformat = pixfmt_cap;
format.fmt.pix_mp.width = orig_pixmp.width;
format.fmt.pix_mp.height = orig_pixmp.height;
venc_try_fmt_common(inst, );

-   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
-   inst->out_width = format.fmt.pix_mp.width;
-   inst->out_height = format.fmt.pix_mp.height;
-   inst->colorspace = pixmp->colorspace;
-   inst->ycbcr_enc = pixmp->ycbcr_enc;
-   inst->quantization = pixmp->quantization;
-   inst->xfer_func = pixmp->xfer_func;
+   if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE) {
+   inst->width = format.fmt.pix_mp.width;
+   inst->height = format.fmt.pix_mp.height;
}

memset(, 0, sizeof(format));

-   format.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
-   format.fmt.pix_mp.pixelformat = pixfmt_cap;
+   format.type = V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE;
+   format.fmt.pix_mp.pixelformat = pixfmt_out;
format.fmt.pix_mp.width = orig_pixmp.width;
format.fmt.pix_mp.height = orig_pixmp.height;
venc_try_fmt_common(inst, );

-   inst->width = format.fmt.pix_mp.width;
-   inst->height = format.fmt.pix_mp.height;
+   inst->out_width = format.fmt.pix_mp.width;
+   inst->out_height = format.fmt.pix_mp.height;
+   if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) {
+   inst->colorspace = pixmp->colorspace;
+   inst->ycbcr_enc = pixmp->ycbcr_enc;
+   inst->quantization = pixmp->quantization;
+   inst->xfer_func = pixmp->xfer_func;
+   }

if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE)
inst->fmt_out = fmt;


RE: [PATCH v2 7/9] riscv: dts: add initial support for the SiFive FU740-C000 SoC

2020-12-15 Thread Yash Shah
> -Original Message-
> From: Bin Meng 
> Sent: 16 December 2020 11:36
> To: Yash Shah 
> Cc: linux-...@vger.kernel.org; linux-ser...@vger.kernel.org; linux-
> p...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel  ker...@vger.kernel.org>; linux-riscv ;
> devicetree ; open list:GPIO SUBSYSTEM  g...@vger.kernel.org>; broo...@kernel.org; Greg Kroah-Hartman
> ; Albert Ou ;
> lee.jo...@linaro.org; u.kleine-koe...@pengutronix.de; Thierry Reding
> ; and...@lunn.ch; Peter Korsgaard
> ; Paul Walmsley ( Sifive)
> ; Palmer Dabbelt ; Rob
> Herring ; Bartosz Golaszewski
> ; Linus Walleij 
> Subject: Re: [PATCH v2 7/9] riscv: dts: add initial support for the SiFive 
> FU740-
> C000 SoC
> 
> [External Email] Do not click links or attachments unless you recognize the
> sender and know the content is safe
> 
> Hi Yash,
> 
> On Wed, Dec 16, 2020 at 1:24 PM Yash Shah 
> wrote:
> >
> > > -Original Message-
> > > From: Bin Meng 
> > > Sent: 10 December 2020 19:05
> > > To: Yash Shah 
> > > Cc: linux-...@vger.kernel.org; linux-ser...@vger.kernel.org; linux-
> > > p...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel  > > ker...@vger.kernel.org>; linux-riscv
> > > ;
> > > devicetree ; open list:GPIO SUBSYSTEM
> > > ; broo...@kernel.org; Greg
> > > Kroah-Hartman ; Albert Ou
> > > ; lee.jo...@linaro.org;
> > > u.kleine-koe...@pengutronix.de; Thierry Reding
> > > ; and...@lunn.ch; Peter Korsgaard
> > > ; Paul Walmsley ( Sifive)
> > > ; Palmer Dabbelt ;
> Rob
> > > Herring ; Bartosz Golaszewski
> > > ; Linus Walleij
> > > 
> > > Subject: Re: [PATCH v2 7/9] riscv: dts: add initial support for the
> > > SiFive FU740-
> > > C000 SoC
> > >
> > > [External Email] Do not click links or attachments unless you
> > > recognize the sender and know the content is safe
> > >
> > > On Tue, Dec 8, 2020 at 3:06 PM Yash Shah 
> wrote:
> > > >
> > > > Add initial support for the SiFive FU540-C000 SoC. FU740-C000 is
> > > > built
> > >
> > > FU740-C000 Soc
> > >
> > > > around the SiFIve U7 Core Complex and a TileLink interconnect.
> > > >
> > > > This file is expected to grow as more device drivers are added to
> > > > the kernel.
> > > >
> > > > Signed-off-by: Yash Shah 
> > > > ---
> > > >  arch/riscv/boot/dts/sifive/fu740-c000.dtsi | 293
> > > > +
> > > >  1 file changed, 293 insertions(+)  create mode 100644
> > > > arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > >
> > > > diff --git a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > > b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > > new file mode 100644
> > > > index 000..eeb4f8c3
> > > > --- /dev/null
> > > > +++ b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > > @@ -0,0 +1,293 @@
> >
> > ...
> >
> > > > +   plic0: interrupt-controller@c00 {
> > > > +   #interrupt-cells = <1>;
> > > > +   #address-cells = <0>;
> > > > +   compatible = "sifive,fu540-c000-plic",
> > > > + "sifive,plic-1.0.0";
> > >
> > > I don't see bindings updated for FU740 PLIC, like 
> > > "sifive,fu740-c000-plic"?
> >
> > That's because it is not required. There won't be any difference in driver
> code for FU740 plic.
> 
> Are there any driver changes for the drivers that have an updated
> fu640-c000-* bindings? I don't see them in the linux-riscv list.

Yes, they will be posted soon.

- Yash

> 
> >
> > ...
> >
> > > > +   eth0: ethernet@1009 {
> > > > +   compatible = "sifive,fu540-c000-gem";
> > >
> > > "sifive,fu740-c000-gem"?
> > >
> >
> > Same reason as above.
> >
> > Thanks for your review.
> 
> Regards,
> Bin


Re: [PATCH v1 5/8] usb: chipidea: tegra: Support host mode

2020-12-15 Thread Peter Chen
On 20-12-15 23:21:10, Dmitry Osipenko wrote:
> From: Peter Geis 
>  
>  struct tegra_usb_soc_info {
>   unsigned long flags;
> + unsigned int txfifothresh;
> + enum usb_dr_mode dr_mode;
> +};
> +
> +static const struct tegra_usb_soc_info tegra20_ehci_soc_info = {
> + .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
> +  CI_HDRC_OVERRIDE_PHY_CONTROL,
> + .dr_mode = USB_DR_MODE_HOST,
> + .txfifothresh = 10,
> +};
> +
> +static const struct tegra_usb_soc_info tegra30_ehci_soc_info = {
> + .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
> +  CI_HDRC_OVERRIDE_PHY_CONTROL
> + .dr_mode = USB_DR_MODE_HOST,
> + .txfifothresh = 16,
>  };
>  
>  static const struct tegra_usb_soc_info tegra_udc_soc_info = {
> - .flags = CI_HDRC_REQUIRES_ALIGNED_DMA,
> + .flags = CI_HDRC_REQUIRES_ALIGNED_DMA |
> +  CI_HDRC_OVERRIDE_PHY_CONTROL,
> + .dr_mode = USB_DR_MODE_UNKNOWN,
>  };

What's the usage for this dr_mode? Does these three SoCs only supports
single mode, it usually sets dr_mode at board dts file to indicate
USB role for this board.

>  
>  static const struct of_device_id tegra_usb_of_match[] = {
>   {
> + .compatible = "nvidia,tegra20-ehci",
> + .data = _ehci_soc_info,
> + }, {
> + .compatible = "nvidia,tegra30-ehci",
> + .data = _ehci_soc_info,
> + }, {
>   .compatible = "nvidia,tegra20-udc",
>   .data = _udc_soc_info,

Your compatible indicates this controller is single USB role, is it
on purpose?

>   }, {
> @@ -47,6 +81,181 @@ static const struct of_device_id tegra_usb_of_match[] = {
>  };
>  MODULE_DEVICE_TABLE(of, tegra_usb_of_match);
>  
> +static int tegra_usb_reset_controller(struct device *dev)
> +{
> + struct reset_control *rst, *rst_utmi;
> + struct device_node *phy_np;
> + int err;
> +
> + rst = devm_reset_control_get_shared(dev, "usb");
> + if (IS_ERR(rst)) {
> + dev_err(dev, "can't get ehci reset: %pe\n", rst);
> + return PTR_ERR(rst);
> + }
> +
> + phy_np = of_parse_phandle(dev->of_node, "nvidia,phy", 0);
> + if (!phy_np)
> + return -ENOENT;
> +
> + /*
> +  * The 1st USB controller contains some UTMI pad registers that are
> +  * global for all the controllers on the chip. Those registers are
> +  * also cleared when reset is asserted to the 1st controller.
> +  */
> + rst_utmi = of_reset_control_get_shared(phy_np, "utmi-pads");
> + if (IS_ERR(rst_utmi)) {
> + dev_warn(dev, "can't get utmi-pads reset from the PHY\n");
> + dev_warn(dev, "continuing, but please update your DT\n");
> + } else {
> + /*
> +  * PHY driver performs UTMI-pads reset in a case of a
> +  * non-legacy DT.
> +  */
> + reset_control_put(rst_utmi);
> + }
> +
> + of_node_put(phy_np);
> +
> + /* reset control is shared, hence initialize it first */
> + err = reset_control_deassert(rst);
> + if (err)
> + return err;
> +
> + err = reset_control_assert(rst);
> + if (err)
> + return err;
> +
> + udelay(1);
> +
> + err = reset_control_deassert(rst);
> + if (err)
> + return err;
> +
> + return 0;
> +}
> +
> +static int tegra_usb_notify_event(struct ci_hdrc *ci, unsigned int event)
> +{
> + struct tegra_usb *usb = dev_get_drvdata(ci->dev->parent);
> + struct ehci_hcd *ehci;
> +
> + switch (event) {
> + case CI_HDRC_CONTROLLER_RESET_EVENT:
> + if (ci->hcd) {
> + ehci = hcd_to_ehci(ci->hcd);
> + ehci->has_tdi_phy_lpm = false;
> + ehci_writel(ehci, usb->soc->txfifothresh << 16,
> + >regs->txfill_tuning);
> + }
> + break;
> + }
> +
> + return 0;
> +}
> +
> +static int tegra_usb_internal_port_reset(struct ehci_hcd *ehci,
> +  u32 __iomem *portsc_reg,
> +  unsigned long *flags)
> +{
> + u32 saved_usbintr, temp;
> + unsigned int i, tries;
> + int retval = 0;
> +
> + saved_usbintr = ehci_readl(ehci, >regs->intr_enable);
> + /* disable USB interrupt */
> + ehci_writel(ehci, 0, >regs->intr_enable);
> + spin_unlock_irqrestore(>lock, *flags);
> +
> + /*
> +  * Here we have to do Port Reset at most twice for
> +  * Port Enable bit to be set.
> +  */
> + for (i = 0; i < 2; i++) {
> + temp = ehci_readl(ehci, portsc_reg);
> + temp |= PORT_RESET;
> + ehci_writel(ehci, temp, portsc_reg);
> + mdelay(10);

Needs accurate delay? How about usleep_range?

> + temp &= ~PORT_RESET;
> + ehci_writel(ehci, temp, portsc_reg);
> + mdelay(1);
> + tries = 100;
> + do {
> +

Re: [PATCH] dax: fix memory leak when rmmod dax.ko

2020-12-15 Thread Dan Williams
On Tue, Dec 1, 2020 at 5:54 AM Wang Hai  wrote:
>
> When I repeatedly modprobe and rmmod dax.ko, kmemleak report a
> memory leak as follows:
>
> unreferenced object 0x9a5588c05088 (size 8):
>   comm "modprobe", pid 261, jiffies 4294693644 (age 42.063s)
> ...
>   backtrace:
> [] kstrdup+0x35/0x70
> [<2ae73897>] kstrdup_const+0x3d/0x50
> [<2b00c9c3>] kvasprintf_const+0xbc/0xf0
> [<8023282f>] kobject_set_name_vargs+0x3b/0xd0
> [] kobject_set_name+0x62/0x90
> [<202e7a22>] bus_register+0x7f/0x2b0
> [<0b77792c>] 0xc02840f7
> [<2d5be5ac>] 0xc02840b4
> [] do_one_initcall+0x58/0x240
> [<049fe480>] do_init_module+0x56/0x1e2
> [<22671491>] load_module+0x2517/0x2840
> [<1a2201cb>] __do_sys_finit_module+0x9c/0xe0
> [<3eb304e7>] do_syscall_64+0x33/0x40
> [<51c5fd06>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> When rmmod dax is executed, dax_bus_exit() is missing. This patch
> can fix this bug.
>
> Fixes: 9567da0b408a ("device-dax: Introduce bus + driver model")
> Reported-by: Hulk Robot 
> Signed-off-by: Wang Hai 

Looks good, applied.

...with some fixups to the changelog to add Cc: stable and change the
title to "device-dax/core: Fix..."


Re: [PATCH v2 7/9] riscv: dts: add initial support for the SiFive FU740-C000 SoC

2020-12-15 Thread Bin Meng
Hi Yash,

On Wed, Dec 16, 2020 at 1:24 PM Yash Shah  wrote:
>
> > -Original Message-
> > From: Bin Meng 
> > Sent: 10 December 2020 19:05
> > To: Yash Shah 
> > Cc: linux-...@vger.kernel.org; linux-ser...@vger.kernel.org; linux-
> > p...@vger.kernel.org; linux-...@vger.kernel.org; linux-kernel  > ker...@vger.kernel.org>; linux-riscv ;
> > devicetree ; open list:GPIO SUBSYSTEM  > g...@vger.kernel.org>; broo...@kernel.org; Greg Kroah-Hartman
> > ; Albert Ou ;
> > lee.jo...@linaro.org; u.kleine-koe...@pengutronix.de; Thierry Reding
> > ; and...@lunn.ch; Peter Korsgaard
> > ; Paul Walmsley ( Sifive)
> > ; Palmer Dabbelt ; Rob
> > Herring ; Bartosz Golaszewski
> > ; Linus Walleij 
> > Subject: Re: [PATCH v2 7/9] riscv: dts: add initial support for the SiFive 
> > FU740-
> > C000 SoC
> >
> > [External Email] Do not click links or attachments unless you recognize the
> > sender and know the content is safe
> >
> > On Tue, Dec 8, 2020 at 3:06 PM Yash Shah  wrote:
> > >
> > > Add initial support for the SiFive FU540-C000 SoC. FU740-C000 is built
> >
> > FU740-C000 Soc
> >
> > > around the SiFIve U7 Core Complex and a TileLink interconnect.
> > >
> > > This file is expected to grow as more device drivers are added to the
> > > kernel.
> > >
> > > Signed-off-by: Yash Shah 
> > > ---
> > >  arch/riscv/boot/dts/sifive/fu740-c000.dtsi | 293
> > > +
> > >  1 file changed, 293 insertions(+)
> > >  create mode 100644 arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > >
> > > diff --git a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > new file mode 100644
> > > index 000..eeb4f8c3
> > > --- /dev/null
> > > +++ b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
> > > @@ -0,0 +1,293 @@
>
> ...
>
> > > +   plic0: interrupt-controller@c00 {
> > > +   #interrupt-cells = <1>;
> > > +   #address-cells = <0>;
> > > +   compatible = "sifive,fu540-c000-plic",
> > > + "sifive,plic-1.0.0";
> >
> > I don't see bindings updated for FU740 PLIC, like "sifive,fu740-c000-plic"?
>
> That's because it is not required. There won't be any difference in driver 
> code for FU740 plic.

Are there any driver changes for the drivers that have an updated
fu640-c000-* bindings? I don't see them in the linux-riscv list.

>
> ...
>
> > > +   eth0: ethernet@1009 {
> > > +   compatible = "sifive,fu540-c000-gem";
> >
> > "sifive,fu740-c000-gem"?
> >
>
> Same reason as above.
>
> Thanks for your review.

Regards,
Bin


Re: [PATCH v3 3/5] RISC-V: Align the .init.text section

2020-12-15 Thread Palmer Dabbelt

On Wed, 04 Nov 2020 16:04:37 PST (-0800), Atish Patra wrote:

In order to improve kernel text protection, we need separate .init.text/
.init.data/.text in separate sections. However, RISC-V linker relaxation
code is not aware of any alignment between sections. As a result, it may
relax any RISCV_CALL relocations between sections to JAL without realizing
that an inter section alignment may move the address farther. That may
lead to a relocation truncated fit error. However, linker relaxation code
is aware of the individual section alignments.

The detailed discussion on this issue can be found here.
https://github.com/riscv/riscv-gnu-toolchain/issues/738

Keep the .init.text section aligned so that linker relaxation will take
that as a hint while relaxing inter section calls.
Here are the code size changes for each section because of this change.

section change in size (in bytes)
  .head.text  +4
  .text   +40
  .init.text  +6530
  .exit.text  +84

The only significant increase in size happened for .init.text because
all intra relocations also use 2MB alignment.

Suggested-by: Jim Wilson 
Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/vmlinux.lds.S | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
index 3ffbd6cbdb86..cacd7898ba7f 100644
--- a/arch/riscv/kernel/vmlinux.lds.S
+++ b/arch/riscv/kernel/vmlinux.lds.S
@@ -30,7 +30,13 @@ SECTIONS
. = ALIGN(PAGE_SIZE);

__init_begin = .;
-   INIT_TEXT_SECTION(PAGE_SIZE)
+   __init_text_begin = .;
+   .init.text : AT(ADDR(.init.text) - LOAD_OFFSET) ALIGN(SECTION_ALIGN) { \
+   _sinittext = .; \
+   INIT_TEXT   \
+   _einittext = .; \
+   }
+
. = ALIGN(8);
__soc_early_init_table : {
__soc_early_init_table_start = .;


Not sure what's going on here (or why I wasn't catching it earlier), but this
is breaking boot on one of my test configs.  I'm not getting any Linux boot
spew, so it's something fairly early.  I'm running defconfig with

   CONFIG_PREEMPT=y
   CONFIG_DEBUG_PREEMPT=y
   CONFIG_PROVE_LOCKING=y

It looks like that's been throwing a bunch of warnings for a while, but it did
at least used to boot.  No idea what PREEMPT would have to do with this, and
the other two don't generally trigger issues that early in boot (or at least,
trigger halts that early in boot).

There's a bunch of other stuff that depends on this that's on for-next so I
don't want to just drop it, but I also don't want to break something.  I'm just
running QEMU's virt board.

I'll take a look again tomorrow night, but if anyone has some time to look
that'd be great!



Re: [PATCH 06/25] dt-bindings: net: dwmac: Add Tx/Rx clock sources

2020-12-15 Thread Serge Semin
On Tue, Dec 15, 2020 at 11:32:04AM -0600, Rob Herring wrote:
> On Mon, Dec 14, 2020 at 12:15:56PM +0300, Serge Semin wrote:
> > Generic DW *MAC can be connected to an external Tramit and Receive clock
> 

> s/Tramit/Transmit/

Thanks. I'll fix it in v2.

-Sergey

> 
> > generators. Add the corresponding clocks description and clock-names to
> > the generic bindings schema so new DW *MAC-based bindings wouldn't declare
> > its own names of the same clocks.
> > 
> > Signed-off-by: Serge Semin 
> > ---
> >  .../devicetree/bindings/net/snps,dwmac.yaml| 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml 
> > b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > index e1ebe5c8b1da..74820f491346 100644
> > --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml
> > @@ -126,6 +126,18 @@ properties:
> >MCI, CSR and SMA interfaces run on this clock. If it's omitted,
> >the CSR interfaces are considered as synchronous to the system
> >clock domain.
> > +  - description:
> > +  GMAC Tx clock or so called Transmit clock. The clock is supplied
> > +  by an external with respect to the DW MAC clock generator.
> > +  The clock source and its frequency depends on the DW MAC xMII 
> > mode.
> > +  In case if it's supplied by PHY/SerDes this property can be
> > +  omitted.
> > +  - description:
> > +  GMAC Rx clock or so called Receive clock. The clock is supplied
> > +  by an external with respect to the DW MAC clock generator.
> > +  The clock source and its frequency depends on the DW MAC xMII 
> > mode.
> > +  In case if it's supplied by PHY/SerDes or it's synchronous to
> > +  the Tx clock this property can be omitted.
> >- description:
> >PTP reference clock. This clock is used for programming the
> >Timestamp Addend Register. If not passed then the system
> > @@ -139,6 +151,8 @@ properties:
> >enum:
> >  - stmmaceth
> >  - pclk
> > +- tx
> > +- rx
> >  - ptp_ref
> >  
> >resets:
> > -- 
> > 2.29.2
> > 


Re: [PATCH -next] leds: leds-ariel: convert comma to semicolon

2020-12-15 Thread Alexander Dahl
Hello,

> Zheng Yongjun  hat am 14.12.2020 14:45 geschrieben:
> 
>  
> Replace a comma between expression statements by a semicolon.
> 
> Signed-off-by: Zheng Yongjun 
> ---
>  drivers/leds/leds-ariel.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/leds/leds-ariel.c b/drivers/leds/leds-ariel.c
> index bb68ba23a7d4..49e1bddaa15e 100644
> --- a/drivers/leds/leds-ariel.c
> +++ b/drivers/leds/leds-ariel.c
> @@ -96,14 +96,14 @@ static int ariel_led_probe(struct platform_device *pdev)
>   return -ENOMEM;
>  
>   leds[0].ec_index = EC_BLUE_LED;
> - leds[0].led_cdev.name = "blue:power",
> + leds[0].led_cdev.name = "blue:power";
>   leds[0].led_cdev.default_trigger = "default-on";
>  
>   leds[1].ec_index = EC_AMBER_LED;
> - leds[1].led_cdev.name = "amber:status",
> + leds[1].led_cdev.name = "amber:status";
>  
>   leds[2].ec_index = EC_GREEN_LED;
> - leds[2].led_cdev.name = "green:status",
> + leds[2].led_cdev.name = "green:status";
>   leds[2].led_cdev.default_trigger = "default-on";
>  
>   for (i = 0; i < NLEDS; i++) {

Reviewed-by: Alexander Dahl 

Greets
Alex


Re: [PATCH v2 03/10] regulator: bd9571mwv: rid of using struct bd9571mwv

2020-12-15 Thread Vaittinen, Matti

On Wed, 2020-12-16 at 02:13 +, Yoshihiro Shimoda wrote:
> Hi Geert-san, Matti-san,
> 
> > From: Geert Uytterhoeven, Sent: Wednesday, December 16, 2020 1:13
> > AM
> > On Tue, Dec 15, 2020 at 5:02 PM Geert Uytterhoeven <
> > ge...@linux-m68k.org> wrote:
> > > On Fri, Dec 11, 2020 at 3:03 PM Vaittinen, Matti
> > >  wrote:
> > > > On Fri, 2020-12-11 at 20:27 +0900, Yoshihiro Shimoda wrote:
> 
> > > > > --- a/drivers/regulator/bd9571mwv-regulator.c
> > > > > +++ b/drivers/regulator/bd9571mwv-regulator.c
> > > > > @@ -17,7 +17,7 @@
> > > > >  #include 
> > > > > 
> > > > >  struct bd9571mwv_reg {
> > > > > - struct bd9571mwv *bd;
> > > > > + struct regmap *regmap;
> > > > 
> > > > As a 'nit':
> > > > I might consider adding the dev pointer here to avoid extra
> > > > argument
> > > > with all the bkup_mode functions below. (just pass this struct
> > > > and
> > > > mode). But that's only my preference - feel free to ignore this
> > > > comment
> > > > if patch is Ok to Mark, Marek & Others :)
> > > 
> > > Struct regmap already contains a struct device pointer, but
> > > that's internal
> > > to regmap.
> > > 
> > > Perhaps adding a regmap_device() helper to retrieve the device
> > > pointer
> > > might be worthwhile?
> > 
> > -EEXISTS ;-)
> > 
> > struct device *regmap_get_device(struct regmap *map)
> 
> Thank you for finding this. I'll fix this patch.

Just a small reminder that this device is probably the MFD device, not
the device created for regulator driver. (Regmap is created for MFD).
For prints this only means we're issuing prints as if MFD device
generated them, right? I'm not sure it is the best approach - but I'll
leave this to Mark & others to judge :)

> 
> Best regards,
> Yoshihiro Shimoda
> 



Re: [PATCH -next] dax: pmem: convert comma to semicolon

2020-12-15 Thread Dan Williams
On Mon, Dec 14, 2020 at 5:45 AM Zheng Yongjun  wrote:
>
> Replace a comma between expression statements by a semicolon.
>
> Signed-off-by: Zheng Yongjun 

Thanks, applied.


[rcu:rcu/urgent] BUILD SUCCESS 1b04fa9900263b4e217ca2509fd778b32c2b4eb2

2020-12-15 Thread kernel test robot
allyesconfig
cskydefconfig
alpha   defconfig
xtensa   allyesconfig
h8300allyesconfig
sh   allmodconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386   tinyconfig
i386defconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a003-20201215
x86_64   randconfig-a006-20201215
x86_64   randconfig-a002-20201215
x86_64   randconfig-a005-20201215
x86_64   randconfig-a004-20201215
x86_64   randconfig-a001-20201215
i386 randconfig-a001-20201215
i386 randconfig-a004-20201215
i386 randconfig-a003-20201215
i386 randconfig-a002-20201215
i386 randconfig-a006-20201215
i386 randconfig-a005-20201215
i386 randconfig-a014-20201215
i386 randconfig-a013-20201215
i386 randconfig-a012-20201215
i386 randconfig-a011-20201215
i386 randconfig-a015-20201215
i386 randconfig-a016-20201215
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a016-20201215
x86_64   randconfig-a012-20201215
x86_64   randconfig-a013-20201215
x86_64   randconfig-a015-20201215
x86_64   randconfig-a014-20201215
x86_64   randconfig-a011-20201215

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


[rcu:rcu/next] BUILD SUCCESS ae5633d5117d6ddae554584ec47dd008e9b68667

2020-12-15 Thread kernel test robot
  allmodconfig
powerpc   allnoconfig
x86_64   randconfig-a003-20201215
x86_64   randconfig-a006-20201215
x86_64   randconfig-a002-20201215
x86_64   randconfig-a005-20201215
x86_64   randconfig-a004-20201215
x86_64   randconfig-a001-20201215
i386 randconfig-a001-20201215
i386 randconfig-a004-20201215
i386 randconfig-a003-20201215
i386 randconfig-a002-20201215
i386 randconfig-a006-20201215
i386 randconfig-a005-20201215
i386 randconfig-a014-20201215
i386 randconfig-a013-20201215
i386 randconfig-a012-20201215
i386 randconfig-a011-20201215
i386 randconfig-a015-20201215
i386 randconfig-a016-20201215
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
x86_64   rhel
x86_64   allyesconfig
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a016-20201215
x86_64   randconfig-a012-20201215
x86_64   randconfig-a013-20201215
x86_64   randconfig-a015-20201215
x86_64   randconfig-a014-20201215
x86_64   randconfig-a011-20201215

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


Re: [PATCH] drivers: nvdimm: cleanup include of badblocks.h

2020-12-15 Thread Dan Williams
On Tue, Dec 15, 2020 at 8:36 AM Enrico Weigelt, metux IT consult
 wrote:
>
> * drivers/nvdimm/core.c doesn't use anything from badblocks.h on its own,
>   thus including it isn't needed. There's indeed indirect use, via funcs
>   in nd.h, but this one already includes badblocks.h.
>
> * drivers/nvdimm/claim.c calls stuff from badblocks.h and therefore should
>   include it on its own (instead of relying any other header doing that)
>
> * drivers/nvdimm/btt.h doesn't really need anything from badblocks.h and
>   can easily live with a forward declaration of struct badblocks (just having
>   pointers to it, but not dereferencing it anywhere)

Thanks, looks ok to me.

It was commit aa9ad44a42b4 ("libnvdimm: move poison list functions to
a new 'badrange' file") that left the straggling include in core.c.


Re: [PATCH v12 5/5] leds: mt6360: Add LED driver for MT6360

2020-12-15 Thread kernel test robot
Hi Gene,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on pavel-linux-leds/for-next]
[also build test WARNING on robh/for-next linus/master v5.10 next-20201215]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Gene-Chen/leds-mt6360-Add-LED-driver-for-MT6360/20201210-140617
base:   git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds.git 
for-next
config: x86_64-randconfig-m001-20201215 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0

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

smatch warnings:
drivers/leds/leds-mt6360.c:778 mt6360_led_probe() warn: always true condition 
'(reg >= 0) => (0-u32max >= 0)'

vim +778 drivers/leds/leds-mt6360.c

   714  
   715  static int mt6360_led_probe(struct platform_device *pdev)
   716  {
   717  struct mt6360_priv *priv;
   718  struct fwnode_handle *child;
   719  size_t count;
   720  int i = 0, ret;
   721  
   722  count = device_get_child_node_count(>dev);
   723  if (!count || count > MT6360_MAX_LEDS) {
   724  dev_err(>dev, "No child node or node count over 
max led number %lu\n", count);
   725  return -EINVAL;
   726  }
   727  
   728  priv = devm_kzalloc(>dev, struct_size(priv, leds, count), 
GFP_KERNEL);
   729  if (!priv)
   730  return -ENOMEM;
   731  
   732  priv->leds_count = count;
   733  priv->dev = >dev;
   734  mutex_init(>lock);
   735  
   736  priv->regmap = dev_get_regmap(pdev->dev.parent, NULL);
   737  if (!priv->regmap) {
   738  dev_err(>dev, "Failed to get parent regmap\n");
   739  return -ENODEV;
   740  }
   741  
   742  device_for_each_child_node(>dev, child) {
   743  struct mt6360_led *led = priv->leds + i;
   744  struct led_init_data init_data = { .fwnode = child, };
   745  u32 reg, led_color;
   746  
   747  ret = fwnode_property_read_u32(child, "color", 
_color);
   748  if (ret)
   749  goto out_flash_release;
   750  
   751  if (led_color == LED_COLOR_ID_RGB || led_color == 
LED_COLOR_ID_MULTI)
   752  reg = MT6360_VIRTUAL_MULTICOLOR;
   753  else {
   754  ret = fwnode_property_read_u32(child, "reg", 
);
   755  if (ret)
   756  goto out_flash_release;
   757  
   758  if (reg >= MT6360_MAX_LEDS) {
   759  ret = -EINVAL;
   760  goto out_flash_release;
   761  }
   762  }
   763  
   764  if (priv->leds_active & BIT(reg)) {
   765  ret = -EINVAL;
   766  goto out_flash_release;
   767  }
   768  priv->leds_active |= BIT(reg);
   769  
   770  led->led_no = reg;
   771  led->priv = priv;
   772  
   773  ret = mt6360_init_common_properties(led, _data);
   774  if (ret)
   775  goto out_flash_release;
   776  
   777  if (reg == MT6360_VIRTUAL_MULTICOLOR ||
 > 778  (reg >= MT6360_LED_ISNK1 && reg <= 
 > MT6360_LED_ISNKML))
   779  ret = mt6360_init_isnk_properties(led, 
_data);
   780  else
   781  ret = mt6360_init_flash_properties(led, 
_data);
   782  
   783  if (ret)
   784  goto out_flash_release;
   785  
   786  ret = mt6360_led_register(>dev, led, _data);
   787  if (ret)
   788  goto out_flash_release;
   789  
   790  i++;
   791  }
   792  
   793  platform_set_drvdata(pdev, priv);
   794  return 0;
   795  
   796  out_flash_release:
   797  mt6360_v4l2_flash_release(priv);
   798  return ret;
   799  }
   800  

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


.config.gz
Description: application/gzip


Re: [RFC PATCH v3 8/9] md: Implement ->corrupted_range()

2020-12-15 Thread Jane Chu

On 12/15/2020 4:14 AM, Shiyang Ruan wrote:

  #ifdef CONFIG_SYSFS
+int bd_disk_holder_corrupted_range(struct block_device *bdev, loff_t off,
+  size_t len, void *data);
  int bd_link_disk_holder(struct block_device *bdev, struct gendisk *disk);
  void bd_unlink_disk_holder(struct block_device *bdev, struct gendisk *disk);
  #else
+int bd_disk_holder_corrupted_range(struct block_device *bdev, loff_t off,


Did you mean
  static inline int bd_disk_holder_corrupted_range(..
?

thanks,
-jane


+  size_t len, void *data)
+{
+   return 0;
+}
  static inline int bd_link_disk_holder(struct block_device *bdev,
  struct gendisk *disk)


Re: [PATCH] thermal: int340x: Support Alder Lake

2020-12-15 Thread Daniel Lezcano
On 16/12/2020 02:59, srinivas pandruvada wrote:
> On Tue, 2020-11-17 at 11:48 -0800, Srinivas Pandruvada wrote:
>> Add ACPI IDs for thermal drivers for Alder Lake support.
>>
> This patch was not in PULL request.
> It is simple patch, adding ids. Can we send as part of second PULL?

Ah, sorry. I missed it.

Yes, I will send a second PR with.


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog


Re: New objtool warning..

2020-12-15 Thread Linus Torvalds
On Tue, Dec 15, 2020 at 8:49 PM Josh Poimboeuf  wrote:
>
> But yeah, it _might_ be possible to make objtool a little smarter here.
> Gimme the .o file and I can take a look tomorrow.

Hmm. I tried to send it to you, but then I get a bounce with

  554 Email rejected due to security policies

because apparently your redhat address doesn't allow object files.

Annoying.

I'll try sending it as a tar-file instead ;)

Linus


  1   2   3   4   5   6   7   8   9   10   >