Re: [PATCH] ARM: aspeed: ast2500 is ARMv6K
On Thu, 19 Sep 2019, at 23:56, Arnd Bergmann wrote: > Linux supports both the original ARMv6 level (early ARM1136) and ARMv6K > (later ARM1136, ARM1176 and ARM11mpcore). > > ast2500 falls into the second categoy, being based on arm1176jzf-s. > This is enabled by default when using ARCH_MULTI_V6, so we should > not 'select CPU_V6'. > > Removing this will lead to more efficient use of atomic instructions. > > Signed-off-by: Arnd Bergmann > --- > arch/arm/mach-aspeed/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig > index a293137f5814..163931a03136 100644 > --- a/arch/arm/mach-aspeed/Kconfig > +++ b/arch/arm/mach-aspeed/Kconfig > @@ -26,7 +26,6 @@ config MACH_ASPEED_G4 > config MACH_ASPEED_G5 > bool "Aspeed SoC 5th Generation" > depends on ARCH_MULTI_V6 > - select CPU_V6 > select PINCTRL_ASPEED_G5 if !CC_IS_CLANG Unrelated, but I'm intrigued by this. Looks like I should try compile it with clang and fix the fallout. Andrew
Re: [PATCH] ARM: aspeed: ast2500 is ARMv6K
On Thu, 19 Sep 2019 at 14:27, Arnd Bergmann wrote:
>
> Linux supports both the original ARMv6 level (early ARM1136) and ARMv6K
> (later ARM1136, ARM1176 and ARM11mpcore).
>
> ast2500 falls into the second categoy, being based on arm1176jzf-s.
> This is enabled by default when using ARCH_MULTI_V6, so we should
> not 'select CPU_V6'.
>
> Removing this will lead to more efficient use of atomic instructions.
Wow, nice find.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/arm/mach-aspeed/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
> index a293137f5814..163931a03136 100644
> --- a/arch/arm/mach-aspeed/Kconfig
> +++ b/arch/arm/mach-aspeed/Kconfig
> @@ -26,7 +26,6 @@ config MACH_ASPEED_G4
> config MACH_ASPEED_G5
> bool "Aspeed SoC 5th Generation"
> depends on ARCH_MULTI_V6
> - select CPU_V6
> select PINCTRL_ASPEED_G5 if !CC_IS_CLANG
I can't find any trees with !CC_IS_CLANG here. Is there a problem
building our pinmux driver with Clang?
I tested with this patch:
--- a/arch/arm/mach-aspeed/Kconfig
+++ b/arch/arm/mach-aspeed/Kconfig
@@ -25,8 +25,8 @@ config MACH_ASPEED_G4
config MACH_ASPEED_G5
bool "Aspeed SoC 5th Generation"
+ # This implies ARMv6K which covers the ARM1176
depends on ARCH_MULTI_V6
- select CPU_V6
select PINCTRL_ASPEED_G5
select FTTMR010_TIMER
help
If you want to apply that as a fix for 5.4 I would be happy with that.
Fixes: 8c2ed9bcfbeb ("arm: Add Aspeed machine")
Reviewed-by: Joel Stanley
Cheers,
Joel
Re: drivers/crypto/inside-secure/safexcel.c:840:9: error: implicit declaration of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'?
Herbert,
This has been fixed in below patch, but I can't find it in linux-next.
https://patchwork.kernel.org/patch/11129983/
On 2019/9/20 9:03, kbuild test robot wrote:
> Hi Pascal,
>
> FYI, the error/warning still remains.
>
> tree:
> https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
> master
> head: 574cc4539762561d96b456dbc0544d8898bd4c6e
> commit: 625f269a5a7a3643771320387e474bd0a61d9654 crypto: inside-secure - add
> support for PCI based FPGA development board
> date: 3 weeks ago
> config: sh-allmodconfig (attached as .config)
> compiler: sh4-linux-gcc (GCC) 7.4.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 625f269a5a7a3643771320387e474bd0a61d9654
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=sh
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
>drivers/crypto/inside-secure/safexcel.c: In function
> 'safexcel_request_ring_irq':
>>> drivers/crypto/inside-secure/safexcel.c:840:9: error: implicit declaration
>>> of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'?
>>> [-Werror=implicit-function-declaration]
> irq = pci_irq_vector(pci_pdev, irqid);
> ^~
> rcu_irq_enter
>drivers/crypto/inside-secure/safexcel.c: In function
> 'safexcel_probe_generic':
>>> drivers/crypto/inside-secure/safexcel.c:1043:9: error: implicit declaration
>>> of function 'pci_alloc_irq_vectors'; did you mean 'pci_alloc_consistent'?
>>> [-Werror=implicit-function-declaration]
> ret = pci_alloc_irq_vectors(pci_pdev,
> ^
> pci_alloc_consistent
>>> drivers/crypto/inside-secure/safexcel.c:1046:10: error: 'PCI_IRQ_MSI'
>>> undeclared (first use in this function); did you mean 'IRQ_MSK'?
> PCI_IRQ_MSI | PCI_IRQ_MSIX);
> ^~~
> IRQ_MSK
>drivers/crypto/inside-secure/safexcel.c:1046:10: note: each undeclared
> identifier is reported only once for each function it appears in
>>> drivers/crypto/inside-secure/safexcel.c:1046:24: error: 'PCI_IRQ_MSIX'
>>> undeclared (first use in this function); did you mean 'PCI_IRQ_MSI'?
> PCI_IRQ_MSI | PCI_IRQ_MSIX);
>^~~~
>PCI_IRQ_MSI
>drivers/crypto/inside-secure/safexcel.c: In function 'safexcel_init':
>drivers/crypto/inside-secure/safexcel.c:1402:6: warning: unused variable
> 'rc' [-Wunused-variable]
> int rc;
> ^~
>cc1: some warnings being treated as errors
>
> vim +840 drivers/crypto/inside-secure/safexcel.c
>
>826
>827static int safexcel_request_ring_irq(void *pdev, int irqid,
>828 int is_pci_dev,
>829 irq_handler_t handler,
>830 irq_handler_t
> threaded_handler,
>831 struct
> safexcel_ring_irq_data *ring_irq_priv)
>832{
>833int ret, irq;
>834struct device *dev;
>835
>836if (IS_ENABLED(CONFIG_PCI) && is_pci_dev) {
>837struct pci_dev *pci_pdev = pdev;
>838
>839dev = _pdev->dev;
> > 840irq = pci_irq_vector(pci_pdev, irqid);
>841if (irq < 0) {
>842dev_err(dev, "unable to get device MSI
> IRQ %d (err %d)\n",
>843irqid, irq);
>844return irq;
>845}
>846} else if (IS_ENABLED(CONFIG_OF)) {
>847struct platform_device *plf_pdev = pdev;
>848char irq_name[6] = {0}; /* "ringX\0" */
>849
>850snprintf(irq_name, 6, "ring%d", irqid);
>851dev = _pdev->dev;
>852irq = platform_get_irq_byname(plf_pdev,
> irq_name);
>853
>854if (irq < 0) {
>855dev_err(dev, "unable to get IRQ '%s'
> (err %d)\n",
>856irq_name, irq);
>857return irq;
>858}
>859}
>860
>861ret = devm_request_threaded_irq(dev, irq, handler,
>862threaded_handler,
> IRQF_ONESHOT,
>863dev_name(dev),
> ring_irq_priv);
>
[PATCH 2/5] net: ethernet: stmmac: fix warning when w=1 option is used during build
This patch fix the following warning:
warning: variable ‘ret’ set but not used [-Wunused-but-set-variable]
int val, ret;
Signed-off-by: Christophe Roullier
---
drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 7e6619868cc1..167a5e99960a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -184,7 +184,7 @@ static int stm32mp1_set_mode(struct plat_stmmacenet_data
*plat_dat)
{
struct stm32_dwmac *dwmac = plat_dat->bsp_priv;
u32 reg = dwmac->mode_reg;
- int val, ret;
+ int val;
switch (plat_dat->interface) {
case PHY_INTERFACE_MODE_MII:
@@ -220,8 +220,8 @@ static int stm32mp1_set_mode(struct plat_stmmacenet_data
*plat_dat)
}
/* Need to update PMCCLRR (clear register) */
- ret = regmap_write(dwmac->regmap, reg + SYSCFG_PMCCLRR_OFFSET,
- dwmac->ops->syscfg_eth_mask);
+ regmap_write(dwmac->regmap, reg + SYSCFG_PMCCLRR_OFFSET,
+dwmac->ops->syscfg_eth_mask);
/* Update PMCSETR (set register) */
return regmap_update_bits(dwmac->regmap, reg,
--
2.17.1
[PATCH 4/5] ARM: dts: stm32: adjust slew rate for Ethernet
ETH_MDIO slew-rate should be set to "0" instead of "2"
Signed-off-by: Christophe Roullier
---
arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
index df6470133574..7667fe758957 100644
--- a/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi
@@ -239,13 +239,18 @@
,
/* ETH_RGMII_TXD2 */
,
/* ETH_RGMII_TXD3 */
,
/* ETH_RGMII_TX_CTL */
-,
/* ETH_MDIO */
;
/* ETH_MDC */
bias-disable;
drive-push-pull;
- slew-rate = <3>;
+ slew-rate = <2>;
};
pins2 {
+ pinmux = ;
/* ETH_MDIO */
+ bias-disable;
+ drive-push-pull;
+ slew-rate = <0>;
+ };
+ pins3 {
pinmux = ,
/* ETH_RGMII_RXD0 */
,
/* ETH_RGMII_RXD1 */
,
/* ETH_RGMII_RXD2 */
--
2.17.1
[PATCH 0/5] net: ethernet: stmmac: some fixes and optimization
Some improvements (manage syscfg as optional clock, update slew rate of ETH_MDIO pin, Enable gating of the MAC TX clock during TX low-power mode) Fix warning build message when W=1 Christophe Roullier (5): net: ethernet: stmmac: Add support for syscfg clock net: ethernet: stmmac: fix warning when w=1 option is used during build ARM: dts: stm32: remove syscfg clock on stm32mp157c ethernet ARM: dts: stm32: adjust slew rate for Ethernet ARM: dts: stm32: Enable gating of the MAC TX clock during TX low-power mode on stm32mp157c arch/arm/boot/dts/stm32mp157-pinctrl.dtsi | 9 +++- arch/arm/boot/dts/stm32mp157c.dtsi| 7 ++-- .../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 42 --- 3 files changed, 38 insertions(+), 20 deletions(-) -- 2.17.1
[PATCH 3/5] ARM: dts: stm32: remove syscfg clock on stm32mp157c ethernet
Syscfg is now activated automatically when syscfg registers are used Signed-off-by: Christophe Roullier --- arch/arm/boot/dts/stm32mp157c.dtsi | 6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi index 0c4e6ebc3529..f51d6222a0e8 100644 --- a/arch/arm/boot/dts/stm32mp157c.dtsi +++ b/arch/arm/boot/dts/stm32mp157c.dtsi @@ -1285,13 +1285,11 @@ clock-names = "stmmaceth", "mac-clk-tx", "mac-clk-rx", - "ethstp", - "syscfg-clk"; + "ethstp"; clocks = < ETHMAC>, < ETHTX>, < ETHRX>, -< ETHSTP>, -< SYSCFG>; +< ETHSTP>; st,syscon = < 0x4>; snps,mixed-burst; snps,pbl = <2>; -- 2.17.1
[PATCH 5/5] ARM: dts: stm32: Enable gating of the MAC TX clock during TX low-power mode on stm32mp157c
When there is no activity on ethernet phy link, the ETH_GTX_CLK is cut Signed-off-by: Christophe Roullier --- arch/arm/boot/dts/stm32mp157c.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/boot/dts/stm32mp157c.dtsi b/arch/arm/boot/dts/stm32mp157c.dtsi index f51d6222a0e8..d78dfc44a1fb 100644 --- a/arch/arm/boot/dts/stm32mp157c.dtsi +++ b/arch/arm/boot/dts/stm32mp157c.dtsi @@ -1293,6 +1293,7 @@ st,syscon = < 0x4>; snps,mixed-burst; snps,pbl = <2>; + snps,en-tx-lpi-clockgating; snps,axi-config = <_axi_config_0>; snps,tso; status = "disabled"; -- 2.17.1
[PATCH 1/5] net: ethernet: stmmac: Add support for syscfg clock
Add optional support for syscfg clock in dwmac-stm32.c
Now Syscfg clock is activated automatically when syscfg
registers are used
Signed-off-by: Christophe Roullier
---
.../net/ethernet/stmicro/stmmac/dwmac-stm32.c | 36 +--
1 file changed, 25 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
index 4ef041bdf6a1..7e6619868cc1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-stm32.c
@@ -152,23 +152,32 @@ static int stm32mp1_clk_prepare(struct stm32_dwmac
*dwmac, bool prepare)
int ret = 0;
if (prepare) {
- ret = clk_prepare_enable(dwmac->syscfg_clk);
- if (ret)
- return ret;
-
+ if (dwmac->syscfg_clk) {
+ ret = clk_prepare_enable(dwmac->syscfg_clk);
+ if (ret)
+ return ret;
+ }
if (dwmac->clk_eth_ck) {
ret = clk_prepare_enable(dwmac->clk_eth_ck);
if (ret) {
- clk_disable_unprepare(dwmac->syscfg_clk);
+ if (dwmac->syscfg_clk)
+ goto unprepare_syscfg;
return ret;
}
}
} else {
- clk_disable_unprepare(dwmac->syscfg_clk);
+ if (dwmac->syscfg_clk)
+ clk_disable_unprepare(dwmac->syscfg_clk);
+
if (dwmac->clk_eth_ck)
clk_disable_unprepare(dwmac->clk_eth_ck);
}
return ret;
+
+unprepare_syscfg:
+ clk_disable_unprepare(dwmac->syscfg_clk);
+
+ return ret;
}
static int stm32mp1_set_mode(struct plat_stmmacenet_data *plat_dat)
@@ -296,7 +305,7 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
{
struct platform_device *pdev = to_platform_device(dev);
struct device_node *np = dev->of_node;
- int err = 0;
+ int err;
/* Gigabit Ethernet 125MHz clock selection. */
dwmac->eth_clk_sel_reg = of_property_read_bool(np, "st,eth-clk-sel");
@@ -320,13 +329,17 @@ static int stm32mp1_parse_data(struct stm32_dwmac *dwmac,
return PTR_ERR(dwmac->clk_ethstp);
}
- /* Clock for sysconfig */
+ /* Optional Clock for sysconfig */
dwmac->syscfg_clk = devm_clk_get(dev, "syscfg-clk");
if (IS_ERR(dwmac->syscfg_clk)) {
- dev_err(dev, "No syscfg clock provided...\n");
- return PTR_ERR(dwmac->syscfg_clk);
+ err = PTR_ERR(dwmac->syscfg_clk);
+ if (err != -ENOENT)
+ return err;
+ dwmac->syscfg_clk = NULL;
}
+ err = 0;
+
/* Get IRQ information early to have an ability to ask for deferred
* probe if needed before we went too far with resource allocation.
*/
@@ -436,7 +449,8 @@ static int stm32mp1_suspend(struct stm32_dwmac *dwmac)
return ret;
clk_disable_unprepare(dwmac->clk_tx);
- clk_disable_unprepare(dwmac->syscfg_clk);
+ if (dwmac->syscfg_clk)
+ clk_disable_unprepare(dwmac->syscfg_clk);
if (dwmac->clk_eth_ck)
clk_disable_unprepare(dwmac->clk_eth_ck);
--
2.17.1
[PATCH v2 5/5] leds: lm3692x: Use flags from LM3692X_BRT_CTRL
Use LM3692X_RAMP_EN instead of LM3692X_PWM_HYSTER_4LSB since the later is a flag for the PWM register. The actual register value remains unchanged. Signed-off-by: Guido Günther Reviewed-by: Dan Murphy Acked-by: Pavel Machek --- drivers/leds/leds-lm3692x.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index d8a60c7c8077..a404b66b31e5 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -269,7 +269,7 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BRT_CTRL, - LM3692X_BL_ADJ_POL | LM3692X_PWM_HYSTER_4LSB); + LM3692X_BL_ADJ_POL | LM3692X_RAMP_EN); if (ret) goto out; -- 2.23.0.rc1
[PATCH v2 3/5] leds: lm3692x: Handle failure to probe the regulator
Instead use devm_regulator_get_optional since the regulator
is optional and check for errors.
Signed-off-by: Guido Günther
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 31115655f97b..6f6a17ec7c9f 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -337,9 +337,18 @@ static int lm3692x_probe_dt(struct lm3692x_led *led)
return ret;
}
- led->regulator = devm_regulator_get(>client->dev, "vled");
- if (IS_ERR(led->regulator))
+ led->regulator = devm_regulator_get_optional(>client->dev, "vled");
+ if (IS_ERR(led->regulator)) {
+ ret = PTR_ERR(led->regulator);
+ if (ret != -ENODEV) {
+ if (ret != -EPROBE_DEFER)
+ dev_err(>client->dev,
+ "Failed to get vled regulator: %d\n",
+ ret);
+ return ret;
+ }
led->regulator = NULL;
+ }
child = device_get_next_child_node(>client->dev, child);
if (!child) {
--
2.23.0.rc1
[PATCH v2 1/5] leds: lm3692x: Print error value on dev_err
This gives a way better idea what is going on.
Signed-off-by: Guido Günther
Reviewed-by: Dan Murphy
Acked-by: Pavel Machek
---
drivers/leds/leds-lm3692x.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 3d381f2f73d0..487228c2bed2 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -174,19 +174,20 @@ static int lm3692x_brightness_set(struct led_classdev
*led_cdev,
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(>client->dev, "Cannot read/clear faults\n");
+ dev_err(>client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_MSB, brt_val);
if (ret) {
- dev_err(>client->dev, "Cannot write MSB\n");
+ dev_err(>client->dev, "Cannot write MSB: %d\n", ret);
goto out;
}
ret = regmap_write(led->regmap, LM3692X_BRT_LSB, led_brightness_lsb);
if (ret) {
- dev_err(>client->dev, "Cannot write LSB\n");
+ dev_err(>client->dev, "Cannot write LSB: %d\n", ret);
goto out;
}
out:
@@ -203,7 +204,7 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = regulator_enable(led->regulator);
if (ret) {
dev_err(>client->dev,
- "Failed to enable regulator\n");
+ "Failed to enable regulator: %d\n", ret);
return ret;
}
}
@@ -213,7 +214,8 @@ static int lm3692x_init(struct lm3692x_led *led)
ret = lm3692x_fault_check(led);
if (ret) {
- dev_err(>client->dev, "Cannot read/clear faults\n");
+ dev_err(>client->dev, "Cannot read/clear faults: %d\n",
+ ret);
goto out;
}
@@ -409,7 +411,8 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regmap_update_bits(led->regmap, LM3692X_EN, LM3692X_DEVICE_EN, 0);
if (ret) {
- dev_err(>client->dev, "Failed to disable regulator\n");
+ dev_err(>client->dev, "Failed to disable regulator: %d\n",
+ ret);
return ret;
}
@@ -420,7 +423,7 @@ static int lm3692x_remove(struct i2c_client *client)
ret = regulator_disable(led->regulator);
if (ret)
dev_err(>client->dev,
- "Failed to disable regulator\n");
+ "Failed to disable regulator: %d\n", ret);
}
mutex_destroy(>lock);
--
2.23.0.rc1
[PATCH v2 0/5] leds: lm3692x: Probing and flag fixes
The driver currently returns success on init although probing fails and register setup uses flag values from other registers which is confusing when reading the driver. This series cleans this up. Changes from v1: - Add reviewed by's from Dan Murphy, thanks! https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mc183f3f65931371fa9f9ca2e0e83e0b85010f24b https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mb845fac36327a5d5dd03fe7e988eef0eb5626f82 https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#m995bce73dda3e3bd4f0c2e8f98cbd04a39c13832 - As per review comment from Dan Murphy - Don't drop error message when disabling the regulator fails https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#m2ab6dc33b7277b71a197c3747847f1c4d9d9c1d8 - Handle -ENODEV (when the regulator is not set) https://lore.kernel.org/linux-leds/cover.1568772964.git@sigxcpu.org/T/#mf6212c29bbfa37b43200ea2c9744074de4f068ee - Add Acked-by from Pavel Machek, thanks! https://lore.kernel.org/linux-leds/20190919095415.GA29939@amd/ To: Jacek Anaszewski ,Pavel Machek ,Dan Murphy ,linux-l...@vger.kernel.org,linux-kernel@vger.kernel.org Guido Günther (5): leds: lm3692x: Print error value on dev_err leds: lm3692x: Don't overwrite return value in error path leds: lm3692x: Handle failure to probe the regulator leds: lm3692x: Use flags from LM3692X_BOOST_CTRL leds: lm3692x: Use flags from LM3692X_BRT_CTRL drivers/leds/leds-lm3692x.c | 45 - 1 file changed, 29 insertions(+), 16 deletions(-) -- 2.23.0.rc1
[PATCH v2 2/5] leds: lm3692x: Don't overwrite return value in error path
The driver currently reports successful initialization on every failure
as long as it's able to power off the regulator. Don't check the return
value of regulator_disable to avoid that.
Signed-off-by: Guido Günther
---
drivers/leds/leds-lm3692x.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c
index 487228c2bed2..31115655f97b 100644
--- a/drivers/leds/leds-lm3692x.c
+++ b/drivers/leds/leds-lm3692x.c
@@ -198,7 +198,7 @@ static int lm3692x_brightness_set(struct led_classdev
*led_cdev,
static int lm3692x_init(struct lm3692x_led *led)
{
int enable_state;
- int ret;
+ int ret, ret2;
if (led->regulator) {
ret = regulator_enable(led->regulator);
@@ -313,14 +313,15 @@ static int lm3692x_init(struct lm3692x_led *led)
gpiod_direction_output(led->enable_gpio, 0);
if (led->regulator) {
- ret = regulator_disable(led->regulator);
- if (ret)
+ ret2 = regulator_disable(led->regulator);
+ if (ret2)
dev_err(>client->dev,
"Failed to disable regulator\n");
}
return ret;
}
+
static int lm3692x_probe_dt(struct lm3692x_led *led)
{
struct fwnode_handle *child = NULL;
--
2.23.0.rc1
[PATCH v2 4/5] leds: lm3692x: Use flags from LM3692X_BOOST_CTRL
The current setup of LM3692X_BOOST_CTRL uses flags from LM3692X_BRT_CTRL. Use flags from LM3692X_BOOST_CTRL but leave the resulting register value unchanged. Signed-off-by: Guido Günther Reviewed-by: Dan Murphy Acked-by: Pavel Machek --- drivers/leds/leds-lm3692x.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/leds/leds-lm3692x.c b/drivers/leds/leds-lm3692x.c index 6f6a17ec7c9f..d8a60c7c8077 100644 --- a/drivers/leds/leds-lm3692x.c +++ b/drivers/leds/leds-lm3692x.c @@ -250,9 +250,9 @@ static int lm3692x_init(struct lm3692x_led *led) goto out; ret = regmap_write(led->regmap, LM3692X_BOOST_CTRL, - LM3692X_BRHT_MODE_RAMP_MULTI | - LM3692X_BL_ADJ_POL | - LM3692X_RAMP_RATE_250us); + LM3692X_BOOST_SW_1MHZ | + LM3692X_BOOST_SW_NO_SHIFT | + LM3692X_OCP_PROT_1_5A); if (ret) goto out; -- 2.23.0.rc1
Re: [PATCH 17/23] mtd: spi-nor: Fix clearing of QE bit on lock()/unlock()
Hi, Vignesh,
On 09/19/2019 05:33 PM, Vignesh Raghavendra wrote:
> External E-Mail
>
>
> Hi Tudor
>
> [...]
>
> On 17-Sep-19 9:25 PM, tudor.amba...@microchip.com wrote:
>> +static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8
>> status_new,
>> +u8 mask)
>> +{
>> +int ret;
>> +u8 *sr_cr = nor->bouncebuf;
>> +u8 cr_written;
>> +
>> +/* Make sure we don't overwrite the contents of Status Register 2. */
>> +if (!(nor->flags & SNOR_F_NO_READ_CR)) {
>
> Assuming SNOR_F_NO_READ_CR is not set...
>
>> +ret = spi_nor_read_cr(nor, _cr[1]);
>> +if (ret)
>> +return ret;
>> +} else if (nor->flash.quad_enable) {
>> +/*
>> + * If the Status Register 2 Read command (35h) is not
>> + * supported, we should at least be sure we don't
>> + * change the value of the SR2 Quad Enable bit.
>> + *
>> + * We can safely assume that when the Quad Enable method is
>> + * set, the value of the QE bit is one, as a consequence of the
>> + * nor->flash.quad_enable() call.
>> + *
>> + * We can safely assume that the Quad Enable bit is present in
>> + * the Status Register 2 at BIT(1). According to the JESD216
>> + * revB standard, BFPT DWORDS[15], bits 22:20, the 16-bit
>> + * Write Status (01h) command is available just for the cases
>> + * in which the QE bit is described in SR2 at BIT(1).
>> + */
>> +sr_cr[1] = CR_QUAD_EN_SPAN;
>> +} else {
>> +sr_cr[1] = 0;
>> +}
>> +
>
> CR_QUAD_EN_SPAN will not be in sr_cr[1] when we reach here. So code
> won't enable quad mode.
>
I get the problem now. spi_nor_write_16bit_sr_and_check() does not modify the
value of the QE bit, which is good in the lock/unlock() case. We want to
lock/unlock() without enabling or disabling the Quad Mode.
As you found, the problem comes later in spi_nor_sr2_bit1_quad_enable() because
I use there spi_nor_write_16bit_sr_and_check() which keeps the value of the QE
bit, without setting it to one, so the spi_nor_sr2_bit1_quad_enable() did not
enable the Quad Mode if not previously enabled.
What I'll do is to introduce a new argument to:
static int spi_nor_write_16bit_sr_and_check(struct spi_nor *nor, u8 status_new,
u8 mask, bool set_quad_enable)
and do a
if (set_quad_enable)
sr_cr[1] |= CR_QUAD_EN_SPAN;
after initializing sr_cr[1]
The lock/unlock() methods will call the function with set_quad_enable being
false (we don't want to modify the QE value), and the
spi_nor_sr2_bit1_quad_enable() will call it with set_quad_enable being true, we
want to set QE to one (we don't care of the QE bit previous value).
We'll avoid code duplication, lock/unlock() and spi_nor_sr2_bit1_quad_enable()
calling the same method.
Cheers,
ta
Re: [RFC {net,iproute2}-next 0/2] Introduce an eBPF hookpoint for tx queue selection in the XPS (Transmit Packet Steering) code.
On Thu, Sep 19, 2019 at 7:45 PM Matt Cover wrote: > > On Thu, Sep 19, 2019 at 6:42 PM Jason Wang wrote: > > > > > > On 2019/9/20 上午8:05, Matt Cover wrote: > > > On Thu, Sep 19, 2019 at 3:45 PM Matthew Cover > > > wrote: > > >> WORK IN PROGRESS: > > >>* bpf program loading works! > > >>* txq steering via bpf program return code works! > > >>* bpf program unloading not working. > > >>* bpf program attached query not working. > > >> > > >> This patch set provides a bpf hookpoint with goals similar to, but a more > > >> generic implementation than, TUNSETSTEERINGEBPF; userspace supplied tx > > >> queue > > >> selection policy. > > > > > > One point that I introduce TUNSETSTEERINGEBPF instead of using a generic > > way like cls/act bpf is that I need make sure to have a consistent API > > with macvtap. > > > > In the case of macvtap, TX means transmit from userspace to kernel, but > > for TUN, it means transmit from kernel to userspace. > > > > Ah, ok. I'll have to check that out at some point. > > > > > >> > > >> TUNSETSTEERINGEBPF is a useful bpf hookpoint, but has some drawbacks. > > >> > > >> First, it only works on tun/tap devices. > > >> > > >> Second, there is no way in the current TUNSETSTEERINGEBPF implementation > > >> to bail out or load a noop bpf prog and fallback to the no prog tx queue > > >> selection method. > > > > > > I believe it expect that eBPF should take all the parts (even the > > fallback part). > > > > This would be easy to change in the existing TUNSETSTEERINGEBPF > implementation if desired. We'd just need a negative return from the bpf prog > to result in falling back to tun_automq_select_queue(). If that behavior > sounds reasonable to you, I can look into that as a separate patch. > > > > > >> > > >> Third, the TUNSETSTEERINGEBPF interface seems to require possession of > > >> existing > > >> or creation of new queues/fds. > > > > > > That's the way TUN work for past +10 years because ioctl is the only way > > to do configuration and it requires a fd to carry that. David suggest to > > implement netlink but nobody did that. > > > > I see. > > > > > >> > > >> This most naturally fits in the "wire" implementation since possession > > >> of fds > > >> is ensured. However, it also means the various "wire" implementations > > >> (e.g. > > >> qemu) have to all be made aware of TUNSETSTEERINGEBPF and expose an > > >> interface > > >> to load/unload a bpf prog (or provide a mechanism to pass an fd to > > >> another > > >> program). > > > > > > The load/unload of ebpf program is standard bpf() syscall. Ioctl just > > attach that to TUN. This idea is borrowed from packet socket which the > > bpf program was attached through setsockopt(). > > > > Yeah, it doesn't take much code to load a prog. I wrote one earlier this week > in fact which spins up an extra fd and detaches right after. > > > > > >> > > >> Alternatively, you can spin up an extra queue and immediately disable via > > >> IFF_DETACH_QUEUE, but this seems unsafe; packets could be enqueued to > > >> this > > >> extra file descriptor which is part of our bpf prog loader, not our > > >> "wire". > > > > > > You can use you 'wire' queue to do ioctl, but we can invent other API. > > > > It might be cool to provide a way to create an already detached fd > (not sure if this > is non-trivial for some reason). Switching over to netlink could be > the more long > term goal. > > > > > >> > > >> Placing this in the XPS code and leveraging iproute2 and rtnetlink to > > >> provide > > >> our bpf prog loader in a similar manner to xdp gives us a nice way to > > >> separate > > >> the tap "wire" and the loading of tx queue selection policy. It also > > >> lets us > > >> use this hookpoint for any device traversing XPS. > > >> > > >> This patch only introduces the new hookpoint to the XPS code and will > > >> not yet > > >> be used by tun/tap devices using the intree tun.ko (which implements an > > >> .ndo_select_queue and does not traverse the XPS code). > > >> > > >> In a future patch set, we can optionally refactor tun.ko to traverse > > >> this call > > >> to bpf_prog_run_clear_cb() and bpf prog storage. tun/tap devices could > > >> then > > >> leverage iproute2 as a generic loader. The TUNSETSTEERINGEBPF interface > > >> could > > >> at this point be optionally deprecated/removed. > > > > > > As described above, we need it for macvtap and you propose here can not > > work for that. > > > > I'm not against this proposal, just want to clarify some considerations > > when developing TUNSETSTEERINGEPF. The main goal is for VM to implement > > sophisticated steering policy like RSS without touching kernel. > > > > Very cool. Thank you for your comments Jason; they have added clarity > to some things. > > I'm still interested in adding this hookpoint, community willing. I > believe it provides > value beyond xps_cpus/xps_rxqs. > > I also plan to look into adding a similar hookpoint in the rps code. > That will
[PATCH] qede: qede_fp: simplify a bit 'qede_rx_build_skb()'
Use 'skb_put_data()' instead of rewritting it. This improves readability. Signed-off-by: Christophe JAILLET --- drivers/net/ethernet/qlogic/qede/qede_fp.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/net/ethernet/qlogic/qede/qede_fp.c b/drivers/net/ethernet/qlogic/qede/qede_fp.c index 0ae28f0d2523..004c0bfec41d 100644 --- a/drivers/net/ethernet/qlogic/qede/qede_fp.c +++ b/drivers/net/ethernet/qlogic/qede/qede_fp.c @@ -779,8 +779,7 @@ qede_rx_build_skb(struct qede_dev *edev, return NULL; skb_reserve(skb, pad); - memcpy(skb_put(skb, len), - page_address(bd->data) + offset, len); + skb_put_data(skb, page_address(bd->data) + offset, len); qede_reuse_page(rxq, bd); goto out; } -- 2.20.1
Re: [PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
On 9/20/2019 9:30 AM, Taniya Das wrote:
Hi Rajendra,
Please pick the patch in the series :
https://patchwork.kernel.org/patch/11150013/
ah, right, not sure how I missed the PATCH 1/3 in the series.
Sorry about the noise.
On 9/19/2019 4:38 PM, Rajendra Nayak wrote:
[]..
+static struct clk_rcg_dfs_data gcc_dfs_clocks[] = {
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s1_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s2_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s3_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s4_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s5_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s0_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s1_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s2_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s3_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s4_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s5_clk_src),
+};
this fails to build..
In file included from drivers/clk/qcom/gcc-sc7180.c:17:0:
drivers/clk/qcom/gcc-sc7180.c:2429:17: error: ‘gcc_qupv3_wrap0_s0_clk_src_src’
undeclared here (not in a function)
DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk_src),
^
drivers/clk/qcom/clk-rcg.h:171:12: note: in definition of macro ‘DEFINE_RCG_DFS’
{ .rcg = ##_src, .init = ##_init }
^
drivers/clk/qcom/gcc-sc7180.c:2430:17: error: ‘gcc_qupv3_wrap0_s1_clk_src_src’
undeclared here (not in a function)
DEFINE_RCG_DFS(gcc_qupv3_wrap0_s1_clk_src),
^
drivers/clk/qcom/clk-rcg.h:171:12: note: in definition of macro ‘DEFINE_RCG_DFS’
{ .rcg = ##_src, .init = ##_init }
^
Perhaps you should drop _src here and in the clk_init_data names.
+
+static const struct regmap_config gcc_sc7180_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x18208c,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc gcc_sc7180_desc = {
+ .config = _sc7180_regmap_config,
+ .clk_hws = gcc_sc7180_hws,
+ .num_clk_hws = ARRAY_SIZE(gcc_sc7180_hws),
+ .clks = gcc_sc7180_clocks,
+ .num_clks = ARRAY_SIZE(gcc_sc7180_clocks),
+ .resets = gcc_sc7180_resets,
+ .num_resets = ARRAY_SIZE(gcc_sc7180_resets),
+ .gdscs = gcc_sc7180_gdscs,
+ .num_gdscs = ARRAY_SIZE(gcc_sc7180_gdscs),
+};
+
+static const struct of_device_id gcc_sc7180_match_table[] = {
+ { .compatible = "qcom,gcc-sc7180" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gcc_sc7180_match_table);
+
+static int gcc_sc7180_probe(struct platform_device *pdev)
+{
+ struct regmap *regmap;
+ int ret;
+
+ regmap = qcom_cc_map(pdev, _sc7180_desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ /*
+ * Disable the GPLL0 active input to MM blocks, NPU
+ * and GPU via MISC registers.
+ */
+ regmap_update_bits(regmap, GCC_MMSS_MISC, 0x3, 0x3);
+ regmap_update_bits(regmap, GCC_NPU_MISC, 0x3, 0x3);
+ regmap_update_bits(regmap, GCC_GPU_MISC, 0x3, 0x3);
+
+ ret = qcom_cc_register_rcg_dfs(regmap, gcc_dfs_clocks,
+ ARRAY_SIZE(gcc_dfs_clocks));
+ if (ret)
+ return ret;
+
+ return qcom_cc_really_probe(pdev, _sc7180_desc, regmap);
+}
+
+static struct platform_driver gcc_sc7180_driver = {
+ .probe = gcc_sc7180_probe,
+ .driver = {
+ .name = "gcc-sc7180",
+ .of_match_table = gcc_sc7180_match_table,
+ },
+};
+
+static int __init gcc_sc7180_init(void)
+{
+ return platform_driver_register(_sc7180_driver);
+}
+subsys_initcall(gcc_sc7180_init);
+
+static void __exit gcc_sc7180_exit(void)
+{
+ platform_driver_unregister(_sc7180_driver);
+}
+module_exit(gcc_sc7180_exit);
+
+MODULE_DESCRIPTION("QTI GCC SC7180 Driver");
+MODULE_LICENSE("GPL v2");
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
Re: [PATCH 19/23] mtd: spi-nor: Rework spansion(_no)_read_cr_quad_enable()
On 09/19/2019 08:34 PM, Vignesh Raghavendra wrote:
>
>
> On 17-Sep-19 9:25 PM, tudor.amba...@microchip.com wrote:
>> From: Tudor Ambarus
>>
>> Merge:
>> spansion_no_read_cr_quad_enable()
>> spansion_read_cr_quad_enable()
>>
>> in spi_nor_sr2_bit1_quad_enable().
>>
>> Avoid duplication of code by using spi_nor_write_16bit_sr_and_check(),
>> the SNOR_F_NO_READ_CR case is treated there.
>>
>> We now do the Read Back test even for the old
>> spansion_no_read_cr_quad_enable() case.
>>
>> Signed-off-by: Tudor Ambarus
>> ---
>> drivers/mtd/spi-nor/spi-nor.c | 89
>> ++-
>> include/linux/mtd/spi-nor.h | 4 +-
>> 2 files changed, 22 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
>> index 2f79923e7db5..8648666fb9bd 100644
>> --- a/drivers/mtd/spi-nor/spi-nor.c
>> +++ b/drivers/mtd/spi-nor/spi-nor.c
>> @@ -907,7 +907,7 @@ static int spi_nor_write_16bit_sr_and_check(struct
>> spi_nor *nor, u8 status_new,
>> * Write Status (01h) command is available just for the cases
>> * in which the QE bit is described in SR2 at BIT(1).
>> */
>> -sr_cr[1] = CR_QUAD_EN_SPAN;
>> +sr_cr[1] = SR2_QUAD_EN_BIT1;
>> } else {
>> sr_cr[1] = 0;
>> }
>> @@ -1963,81 +1963,34 @@ static int spi_nor_sr1_bit6_quad_enable(struct
>> spi_nor *nor)
>> }
>>
>> /**
>> - * spansion_no_read_cr_quad_enable() - set QE bit in Configuration Register.
>> + * spi_nor_sr2_bit1_quad_enable() - set the Quad Enable BIT(1) in the Status
>> + * Register 2.
>> * @nor:pointer to a 'struct spi_nor'
>> *
>> - * Set the Quad Enable (QE) bit in the Configuration Register.
>> - * This function should be used with QSPI memories not supporting the Read
>> - * Configuration Register (35h) instruction.
>> - *
>> - * bit 1 of the Configuration Register is the QE bit for Spansion like QSPI
>> - * memories.
>> - *
>> - * Return: 0 on success, -errno otherwise.
>> - */
>> -static int spansion_no_read_cr_quad_enable(struct spi_nor *nor)
>> -{
>> -u8 *sr_cr = nor->bouncebuf;
>> -int ret;
>> -
>> -/* Keep the current value of the Status Register. */
>> -ret = spi_nor_read_sr(nor, _cr[0]);
>> -if (ret)
>> -return ret;
>> -
>> -sr_cr[1] = CR_QUAD_EN_SPAN;
>> -
>> -return spi_nor_write_sr(nor, sr_cr, 2);
>> -}
>> -
>> -/**
>> - * spansion_read_cr_quad_enable() - set QE bit in Configuration Register.
>> - * @nor:pointer to a 'struct spi_nor'
>> - *
>> - * Set the Quad Enable (QE) bit in the Configuration Register.
>> - * This function should be used with QSPI memories supporting the Read
>> - * Configuration Register (35h) instruction.
>> - *
>> - * bit 1 of the Configuration Register is the QE bit for Spansion like QSPI
>> - * memories.
>> + * Bit 1 of the Status Register 2 is the QE bit for Spansion like QSPI
>> memories.
>> *
>> * Return: 0 on success, -errno otherwise.
>> */
>> -static int spansion_read_cr_quad_enable(struct spi_nor *nor)
>> +static int spi_nor_sr2_bit1_quad_enable(struct spi_nor *nor)
>> {
>> -u8 *sr_cr = nor->bouncebuf;
>> int ret;
>>
>> -/* Check current Quad Enable bit value. */
>> -ret = spi_nor_read_cr(nor, _cr[1]);
>> -if (ret)
>> -return ret;
>> -
>> -if (sr_cr[1] & CR_QUAD_EN_SPAN)
>> -return 0;
>> +if (!(nor->flags & SNOR_F_NO_READ_CR)) {
>> +/* Check current Quad Enable bit value. */
>> +ret = spi_nor_read_cr(nor, >bouncebuf[0]);
>> +if (ret)
>> +return ret;
>>
>> -sr_cr[1] |= CR_QUAD_EN_SPAN;
>> +if (nor->bouncebuf[0] & SR2_QUAD_EN_BIT1)
>> +return 0;
>> +}
>>
>> /* Keep the current value of the Status Register. */
>> -ret = spi_nor_read_sr(nor, _cr[0]);
>> -if (ret)
>> -return ret;
>> -
>> -ret = spi_nor_write_sr(nor, sr_cr, 2);
>> -if (ret)
>> -return ret;
>> -
>> -/* Read back and check it. */
>> -ret = spi_nor_read_cr(nor, _cr[1]);
>> +ret = spi_nor_read_sr(nor, >bouncebuf[0]);
>> if (ret)
>> return ret;
>>
>> -if (!(sr_cr[1] & CR_QUAD_EN_SPAN)) {
>> -dev_err(nor->dev, "Spansion Quad bit not set\n");
>> -return -EIO;
>> -}
>> -
>> -return 0;
>
> You need to set QE bit here before writing to CR register. This function
> does not do that.>
>> +return spi_nor_write_16bit_sr_and_check(nor, nor->bouncebuf[0], 0xFF);>
> Neither does spi_nor_write_16bit_sr_and_check().
pff, you're right, I thought I did set it in spi_nor_write_16bit_sr_and_check(),
but in spi_nor_write_16bit_sr_and_check() I just read the CR, without setting
the QE bit. Will respin the entire series, thanks for catching this!
> We need a function that allows to modify SR2/CR register content as well
> so as to set QE bit right?
>
> Regards
> Vignesh
>
>>
arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of 'pip_sft_rst' isn't known
Hi Matthew, FYI, the error/warning still remains. tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git master head: 574cc4539762561d96b456dbc0544d8898bd4c6e commit: 171a9bae68c72f2d1260c3825203760856e6793b staging/octeon: Allow test build on !MIPS date: 7 weeks ago config: mips-allmodconfig (attached as .config) compiler: mips-linux-gcc (GCC) 7.4.0 reproduce: wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout 171a9bae68c72f2d1260c3825203760856e6793b # save the attached .config to linux build tree GCC_VERSION=7.4.0 make.cross ARCH=mips If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): In file included from arch/mips/include/asm/octeon/octeon.h:11:0, from drivers/staging/octeon/octeon-ethernet.h:19, from drivers/staging/octeon/ethernet-sgmii.c:14: arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr': arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cvmx_write_csr((__force uint64_t)csr_addr, val); ^ arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr': arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return cvmx_read_csr((__force uint64_t) csr_addr); ^ In file included from drivers/staging/octeon/octeon-ethernet.h:27:0, from drivers/staging/octeon/ethernet-sgmii.c:14: arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr': >> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of >> 'pip_sft_rst' isn't known union cvmx_pip_sft_rst pip_sft_rst; ^~~ >> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' >> undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'? pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST); ^~~~ CVMX_CIU_SOFT_RST arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable] union cvmx_pip_sft_rst pip_sft_rst; ^~~ -- In file included from arch/mips/include/asm/octeon/octeon.h:11:0, from drivers/staging/octeon/octeon-ethernet.h:19, from drivers/staging/octeon/ethernet-spi.c:13: arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_writeq_csr': arch/mips/include/asm/octeon/cvmx.h:282:17: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] cvmx_write_csr((__force uint64_t)csr_addr, val); ^ arch/mips/include/asm/octeon/cvmx.h: In function 'cvmx_readq_csr': arch/mips/include/asm/octeon/cvmx.h:299:23: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast] return cvmx_read_csr((__force uint64_t) csr_addr); ^ In file included from drivers/staging/octeon/octeon-ethernet.h:27:0, from drivers/staging/octeon/ethernet-spi.c:13: arch/mips/include/asm/octeon/cvmx-ipd.h: In function 'cvmx_ipd_free_ptr': >> arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: error: storage size of >> 'pip_sft_rst' isn't known union cvmx_pip_sft_rst pip_sft_rst; ^~~ >> arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: error: 'CVMX_PIP_SFT_RST' >> undeclared (first use in this function); did you mean 'CVMX_CIU_SOFT_RST'? pip_sft_rst.u64 = cvmx_read_csr(CVMX_PIP_SFT_RST); ^~~~ CVMX_CIU_SOFT_RST arch/mips/include/asm/octeon/cvmx-ipd.h:331:36: note: each undeclared identifier is reported only once for each function it appears in arch/mips/include/asm/octeon/cvmx-ipd.h:330:27: warning: unused variable 'pip_sft_rst' [-Wunused-variable] union cvmx_pip_sft_rst pip_sft_rst; ^~~ drivers/staging/octeon/ethernet-spi.c: In function 'cvm_oct_spi_init': >> drivers/staging/octeon/ethernet-spi.c:198:19: error: 'OCTEON_IRQ_RML' >> undeclared (first use in this function); did you mean 'OCTEON_IS_MODEL'? r = request_irq(OCTEON_IRQ_RML, cvm_oct_spi_rml_interrupt, ^~ OCTEON_IS_MODEL drivers/staging/octeon/ethernet-spi.c: In function 'cvm_oct_spi_uninit': drivers/staging/octeon/ethernet-spi.c:224:12: error:
Re: [breakage] panic() does not halt arm64 systems under certain conditions
On Tue, Sep 17, 2019 at 11:45:19AM +0100, Will Deacon wrote:
> Hi,
>
> [Expanding CC list; original message is here:
>
> https://lore.kernel.org/linux-arm-kernel/BX1W47JXPMR8.58IYW53H6M5N@dragonstone/]
>
> On Mon, Sep 16, 2019 at 09:35:36PM -0400, Xogium wrote:
> > On arm64 in some situations userspace will continue running even after a
> > panic. This means any userspace watchdog daemon will continue pinging,
> > that service managers will keep running and displaying messages in certain
> > cases, and that it is possible to enter via ssh in the now unstable system
> > and to do almost anything except reboot/power off and etc. If
> > CONFIG_PREEMPT=n is set in the kernel's configuration, the issue is fixed.
> > I have reproduced the very same behavior with linux 4.19, 5.2 and 5.3. On
> > x86/x86_64 the issue does not seem to be present at all.
>
> I've managed to reproduce this under both 32-bit and 64-bit ARM kernels.
> The issue is that the infinite loop at the end of panic() can run with
> preemption enabled (particularly when invoking by echoing 'c' to
> /proc/sysrq-trigger), so we end up rescheduling user tasks. On x86, this
> doesn't happen because smp_send_stop() disables the local APIC in
> native_stop_other_cpus() and so interrupts are effectively masked while
> spinning.
>
> A straightforward fix is to disable preemption explicitly on the panic()
> path (diff below), but I've expanded the cc list to see both what others
> think, but also in case smp_send_stop() is supposed to have the side-effect
> of disabling interrupt delivery for the local CPU.
>
> Will
>
> --->8
>
> diff --git a/kernel/panic.c b/kernel/panic.c
> index 057540b6eee9..02d0de31c42d 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -179,6 +179,7 @@ void panic(const char *fmt, ...)
>* after setting panic_cpu) from invoking panic() again.
>*/
> local_irq_disable();
> + preempt_disable_notrace();
>
> /*
>* It's possible to come here directly from a panic-assertion and
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
When you run with panic=... it will send you to a loop earlier in the
panic code before local_irq_disable() is hit, working around the bug.
A patch like this would make the behaviour the same:
diff --git a/kernel/panic.c b/kernel/panic.c
index 4d9f55bf7d38..92abbb5f8d38 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -331,7 +331,6 @@ void panic(const char *fmt, ...)
/* Do not scroll important messages printed above */
suppress_printk = 1;
- local_irq_enable();
for (i = 0; ; i += PANIC_TIMER_STEP) {
touch_softlockup_watchdog();
if (i >= i_next) {
Re: [RFC v4 3/3] vhost: introduce mdev based hardware backend
On Tue, Sep 17, 2019 at 03:26:30PM +0800, Jason Wang wrote:
> On 2019/9/17 上午9:02, Tiwei Bie wrote:
> > diff --git a/drivers/vhost/mdev.c b/drivers/vhost/mdev.c
> > new file mode 100644
> > index ..8c6597aff45e
> > --- /dev/null
> > +++ b/drivers/vhost/mdev.c
> > @@ -0,0 +1,462 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2018-2019 Intel Corporation.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "vhost.h"
> > +
> > +struct vhost_mdev {
> > + struct mutex mutex;
> > + struct vhost_dev dev;
> > + struct vhost_virtqueue *vqs;
> > + int nvqs;
> > + u64 state;
> > + u64 features;
> > + u64 acked_features;
> > + struct vfio_group *vfio_group;
> > + struct vfio_device *vfio_device;
> > + struct mdev_device *mdev;
> > +};
> > +
> > +/*
> > + * XXX
> > + * We assume virtio_mdev.ko exposes below symbols for now, as we
> > + * don't have a proper way to access parent ops directly yet.
> > + *
> > + * virtio_mdev_readl()
> > + * virtio_mdev_writel()
> > + */
> > +extern u32 virtio_mdev_readl(struct mdev_device *mdev, loff_t off);
> > +extern void virtio_mdev_writel(struct mdev_device *mdev, loff_t off, u32
> > val);
>
>
> Need to consider a better approach, I feel we should do it through some kind
> of mdev driver instead of talk to mdev device directly.
Yeah, a better approach is really needed here.
Besides, we may want a way to allow accessing the mdev
device_ops proposed in below series outside the
drivers/vfio/mdev/ directory.
https://lkml.org/lkml/2019/9/12/151
I.e. allow putting mdev drivers outside above directory.
> > +
> > + for (queue_id = 0; queue_id < m->nvqs; queue_id++) {
> > + vq = >vqs[queue_id];
> > +
> > + if (!vq->desc || !vq->avail || !vq->used)
> > + break;
> > +
> > + virtio_mdev_writel(mdev, VIRTIO_MDEV_QUEUE_NUM, vq->num);
> > +
> > + if (!vhost_translate_ring_addr(vq, (u64)vq->desc,
> > + vhost_get_desc_size(vq, vq->num),
> > + ))
> > + return -EINVAL;
>
>
> Interesting, any reason for doing such kinds of translation to HVA? I
> believe the add should already an IOVA that has been map by VFIO.
Currently, in the software based vhost-kernel and vhost-user
backends, QEMU will pass ring addresses as HVA in SET_VRING_ADDR
ioctl when iotlb isn't enabled. If it's OK to let QEMU pass GPA
in vhost-mdev in this case, then this translation won't be needed.
Thanks,
Tiwei
Re: [PATCH] rpmsg: glink: Fix channel memory leak
On Thu 19 Sep 03:05 PDT 2019, Srinivas Kandagatla wrote:
> If we stop and start the dsp while channel is open then there is a leak
> in the driver as the refcount is not accounted for the open.
>
> This patch checks if the channel is open while running cleanup code
> and does an extra kref_put to account for open which would ensure
> that channel does not leak.
>
> Originally detected by kmemleak:
> backtrace:
> [] kmemleak_alloc+0x50/0x84
> [] kmem_cache_alloc_trace+0xd4/0x178
> [] qcom_glink_alloc_channel+0x34/0x148
> [] qcom_glink_work+0x3b0/0x664
> [] process_one_work+0x160/0x2f8
> [] worker_thread+0x1e8/0x2d4
> [] kthread+0x128/0x138
> [] ret_from_fork+0x10/0x18
> [] 0x
> unreferenced object 0xffc02cf5ed80 (size 128):
>
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/rpmsg/qcom_glink_native.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_native.c
> b/drivers/rpmsg/qcom_glink_native.c
> index dc7d3d098fd3..38a10dcc2029 100644
> --- a/drivers/rpmsg/qcom_glink_native.c
> +++ b/drivers/rpmsg/qcom_glink_native.c
> @@ -1660,8 +1660,13 @@ void qcom_glink_native_remove(struct qcom_glink *glink)
>
> spin_lock_irqsave(>idr_lock, flags);
> /* Release any defunct local channels, waiting for close-ack */
> - idr_for_each_entry(>lcids, channel, cid)
> + idr_for_each_entry(>lcids, channel, cid) {
> + if (channel->rcid)
Thanks for the patch Srinivas! I looked at it in your tree as I was
coming up with the fixes for the problems I hit in my testing the other
day.
But, there is a window between qcom_glink_rx_open() assigning
channel->rcid and where rpmsg_dev_probe() will invoke
qcom_glink_create_remote(), which adds the channel to lcids, i.e. where
we would leak the channel. So I instead picked Chris' patch (3/6 in my
series), which will clean up the channel in this case as well.
Regards,
Bjorn
> + kref_put(>refcount,
> + qcom_glink_channel_release);
> +
> kref_put(>refcount, qcom_glink_channel_release);
> + }
>
> /* Release any defunct local channels, waiting for close-req */
> idr_for_each_entry(>rcids, channel, cid)
> --
> 2.21.0
>
Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
On 09/18/2019 11:52 PM, Gerald Schaefer wrote: > On Wed, 18 Sep 2019 18:26:03 +0200 > Christophe Leroy wrote: > > [..] >> My suggestion was not to completely drop the #ifdef but to do like you >> did in pgd_clear_tests() for instance, ie to add the following test on >> top of the function: >> >> if (mm_pud_folded(mm) || is_defined(__ARCH_HAS_5LEVEL_HACK)) >> return; >> > > Ah, very nice, this would also fix the remaining issues for s390. Since > we have dynamic page table folding, neither __PAGETABLE_PXX_FOLDED nor > __ARCH_HAS_XLEVEL_HACK is defined, but mm_pxx_folded() will work. Like Christophe mentioned earlier on the other thread, we will convert all __PGTABLE_PXX_FOLDED checks as mm_pxx_folded() but looks like ARCH_HAS_[4 and 5]LEVEL_HACK macros will still be around. Will respin the series with all agreed upon changes first and probably we can then discuss pending issues from there. > > mm_alloc() returns with a 3-level page table by default on s390, so we > will run into issues in p4d_clear/populate_tests(), and also at the end > with p4d/pud_free() (double free). > > So, adding the mm_pud_folded() check to p4d_clear/populate_tests(), > and also adding mm_p4d/pud_folded() checks at the end before calling> > p4d/pud_free(), would make it all work on s390. Atleast p4d_clear/populate_tests() tests will be taken care. > > BTW, regarding p4d/pud_free(), I'm not sure if we should rather check > the folding inside our s390 functions, similar to how we do it for > p4d/pud_free_tlb(), instead of relying on not being called for folded > p4d/pud. So far, I see no problem with this behavior, all callers of > p4d/pud_free() should be fine because of our folding check within > p4d/pud_present/none(). But that doesn't mean that it is correct not > to check for the folding inside p4d/pud_free(). At least, with this > test module we do now have a caller of p4d/pud_free() on potentially > folded entries, so instead of adding pxx_folded() checks to this > test module, we could add them to our p4d/pud_free() functions. > Any thoughts on this? Agreed, it seems better to do the check inside p4d/pud_free() functions.
Re: [PATCH 4.4 00/56] 4.4.194-stable review
stable-rc/linux-4.4.y boot: 47 boots: 1 failed, 46 passed (v4.4.193-57-g7b679e1a966b) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.4.y/kernel/v4.4.193-57-g7b679e1a966b/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.4.y/kernel/v4.4.193-57-g7b679e1a966b/ Tree: stable-rc Branch: linux-4.4.y Git Describe: v4.4.193-57-g7b679e1a966b Git Commit: 7b679e1a966bc6ac22d75cae76b97a9fded9367d Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 19 unique boards, 10 SoC families, 8 builds out of 190 Boot Failure Detected: arm64: defconfig: gcc-8: qcom-qdf2400: 1 failed lab --- For more info write to
Re: [PATCH v3 3/3] clk: qcom: Add Global Clock controller (GCC) driver for SC7180
Hi Rajendra,
Please pick the patch in the series :
https://patchwork.kernel.org/patch/11150013/
On 9/19/2019 4:38 PM, Rajendra Nayak wrote:
[]..
+static struct clk_rcg_dfs_data gcc_dfs_clocks[] = {
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s1_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s2_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s3_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s4_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap0_s5_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s0_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s1_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s2_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s3_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s4_clk_src),
+ DEFINE_RCG_DFS(gcc_qupv3_wrap1_s5_clk_src),
+};
this fails to build..
In file included from drivers/clk/qcom/gcc-sc7180.c:17:0:
drivers/clk/qcom/gcc-sc7180.c:2429:17: error:
‘gcc_qupv3_wrap0_s0_clk_src_src’ undeclared here (not in a function)
DEFINE_RCG_DFS(gcc_qupv3_wrap0_s0_clk_src),
^
drivers/clk/qcom/clk-rcg.h:171:12: note: in definition of macro
‘DEFINE_RCG_DFS’
{ .rcg = ##_src, .init = ##_init }
^
drivers/clk/qcom/gcc-sc7180.c:2430:17: error:
‘gcc_qupv3_wrap0_s1_clk_src_src’ undeclared here (not in a function)
DEFINE_RCG_DFS(gcc_qupv3_wrap0_s1_clk_src),
^
drivers/clk/qcom/clk-rcg.h:171:12: note: in definition of macro
‘DEFINE_RCG_DFS’
{ .rcg = ##_src, .init = ##_init }
^
Perhaps you should drop _src here and in the clk_init_data names.
+
+static const struct regmap_config gcc_sc7180_regmap_config = {
+ .reg_bits = 32,
+ .reg_stride = 4,
+ .val_bits = 32,
+ .max_register = 0x18208c,
+ .fast_io = true,
+};
+
+static const struct qcom_cc_desc gcc_sc7180_desc = {
+ .config = _sc7180_regmap_config,
+ .clk_hws = gcc_sc7180_hws,
+ .num_clk_hws = ARRAY_SIZE(gcc_sc7180_hws),
+ .clks = gcc_sc7180_clocks,
+ .num_clks = ARRAY_SIZE(gcc_sc7180_clocks),
+ .resets = gcc_sc7180_resets,
+ .num_resets = ARRAY_SIZE(gcc_sc7180_resets),
+ .gdscs = gcc_sc7180_gdscs,
+ .num_gdscs = ARRAY_SIZE(gcc_sc7180_gdscs),
+};
+
+static const struct of_device_id gcc_sc7180_match_table[] = {
+ { .compatible = "qcom,gcc-sc7180" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, gcc_sc7180_match_table);
+
+static int gcc_sc7180_probe(struct platform_device *pdev)
+{
+ struct regmap *regmap;
+ int ret;
+
+ regmap = qcom_cc_map(pdev, _sc7180_desc);
+ if (IS_ERR(regmap))
+ return PTR_ERR(regmap);
+
+ /*
+ * Disable the GPLL0 active input to MM blocks, NPU
+ * and GPU via MISC registers.
+ */
+ regmap_update_bits(regmap, GCC_MMSS_MISC, 0x3, 0x3);
+ regmap_update_bits(regmap, GCC_NPU_MISC, 0x3, 0x3);
+ regmap_update_bits(regmap, GCC_GPU_MISC, 0x3, 0x3);
+
+ ret = qcom_cc_register_rcg_dfs(regmap, gcc_dfs_clocks,
+ ARRAY_SIZE(gcc_dfs_clocks));
+ if (ret)
+ return ret;
+
+ return qcom_cc_really_probe(pdev, _sc7180_desc, regmap);
+}
+
+static struct platform_driver gcc_sc7180_driver = {
+ .probe = gcc_sc7180_probe,
+ .driver = {
+ .name = "gcc-sc7180",
+ .of_match_table = gcc_sc7180_match_table,
+ },
+};
+
+static int __init gcc_sc7180_init(void)
+{
+ return platform_driver_register(_sc7180_driver);
+}
+subsys_initcall(gcc_sc7180_init);
+
+static void __exit gcc_sc7180_exit(void)
+{
+ platform_driver_unregister(_sc7180_driver);
+}
+module_exit(gcc_sc7180_exit);
+
+MODULE_DESCRIPTION("QTI GCC SC7180 Driver");
+MODULE_LICENSE("GPL v2");
--
Qualcomm INDIA, on behalf of Qualcomm Innovation Center, Inc.is a member
of the Code Aurora Forum, hosted by the Linux Foundation.
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation.
--
Re: [PATCH 5.2 000/124] 5.2.17-stable review
stable-rc/linux-5.2.y boot: 72 boots: 0 failed, 71 passed with 1 conflict (v5.2.16-125-g690411952b3d) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.16-125-g690411952b3d/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.16-125-g690411952b3d/ Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.16-125-g690411952b3d Git Commit: 690411952b3d8cab079b16af04292f93643bb864 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 42 unique boards, 16 SoC families, 12 builds out of 209 Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: omap2plus_defconfig: omap4-panda: lab-baylibre: FAIL (gcc-8) lab-collabora: PASS (gcc-8) --- For more info write to
Re: [PATCH] ARM: aspeed: ast2500 is ARMv6K
On Thu, 19 Sep 2019, at 23:56, Arnd Bergmann wrote: > Linux supports both the original ARMv6 level (early ARM1136) and ARMv6K > (later ARM1136, ARM1176 and ARM11mpcore). > > ast2500 falls into the second categoy, being based on arm1176jzf-s. > This is enabled by default when using ARCH_MULTI_V6, so we should > not 'select CPU_V6'. > > Removing this will lead to more efficient use of atomic instructions. > > Signed-off-by: Arnd Bergmann Reviewed-by: Andrew Jeffery
[PATCH] x86/kdump: Fix 'kmem -s' reported an invalid freepointer when SME was active
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204793 Kdump kernel will reuse the first 640k region because of some reasons, for example: the trampline and conventional PC system BIOS region may require to allocate memory in this area. Obviously, kdump kernel will also overwrite the first 640k region, therefore, kernel has to copy the contents of the first 640k area to a backup area, which is done in purgatory(), because vmcore may need the old memory. When vmcore is dumped, kdump kernel will read the old memory from the backup area of the first 640k area. Basically, the main reason should be clear, kernel does not correctly handle the first 640k region when SME is active, which causes that kernel does not properly copy these old memory to the backup area in purgatory(). Therefore, kdump kernel reads out the incorrect contents from the backup area when dumping vmcore. Finally, the phenomenon is as follow: [root linux]$ crash vmlinux /var/crash/127.0.0.1-2019-09-19-08\:31\:27/vmcore WARNING: kernel relocated [240MB]: patching 97110 gdb minimal_symbol values KERNEL: /var/crash/127.0.0.1-2019-09-19-08:31:27/vmlinux DUMPFILE: /var/crash/127.0.0.1-2019-09-19-08:31:27/vmcore [PARTIAL DUMP] CPUS: 128 DATE: Thu Sep 19 08:31:18 2019 UPTIME: 00:01:21 LOAD AVERAGE: 0.16, 0.07, 0.02 TASKS: 1343 NODENAME: amd-ethanol RELEASE: 5.3.0-rc7+ VERSION: #4 SMP Thu Sep 19 08:14:00 EDT 2019 MACHINE: x86_64 (2195 Mhz) MEMORY: 127.9 GB PANIC: "Kernel panic - not syncing: sysrq triggered crash" PID: 9789 COMMAND: "bash" TASK: "89711894ae80 [THREAD_INFO: 89711894ae80]" CPU: 83 STATE: TASK_RUNNING (PANIC) crash> kmem -s|grep -i invalid kmem: dma-kmalloc-512: slab:d77680001c00 invalid freepointer:a6086ac099f0c5a4 kmem: dma-kmalloc-512: slab:d77680001c00 invalid freepointer:a6086ac099f0c5a4 crash> In order to avoid such problem, lets occupy the first 640k region when SME is active, which will ensure that the allocated memory does not fall into the first 640k area. So, no need to worry about whether kernel can correctly copy the contents of the first 640K area to a backup region in purgatory(). Signed-off-by: Lianbo Jiang --- arch/x86/kernel/setup.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c index 77ea96b794bd..5bfb2c83bb6c 100644 --- a/arch/x86/kernel/setup.c +++ b/arch/x86/kernel/setup.c @@ -1148,6 +1148,9 @@ void __init setup_arch(char **cmdline_p) reserve_real_mode(); + if (sme_active()) + memblock_reserve(0, 640*1024); + trim_platform_memory_ranges(); trim_low_memory_range(); -- 2.17.1
RE: [EXT] [PATCH v3] serial: imx: adapt rx buffer and dma periods
From: Philipp Puschmann Sent: Thursday, September
19, 2019 10:51 PM
> Using only 4 DMA periods for UART RX is very few if we have a high frequency
> of small transfers - like in our case using Bluetooth with many small packets
> via UART - causing many dma transfers but in each only filling a fraction of a
> single buffer. Such a case may lead to the situation that DMA RX transfer is
> triggered but no free buffer is available. When this happens dma channel ist
> stopped - with the patch
> "dmaengine: imx-sdma: fix dma freezes" temporarily only - with the possible
> consequences that:
> with disabled hw flow control:
> If enough data is incoming on UART port the RX FIFO runs over and
> characters will be lost. What then happens depends on upper layer.
>
> with enabled hw flow control:
> If enough data is incoming on UART port the RX FIFO reaches a level
> where CTS is deasserted and remote device sending the data stops.
> If it fails to stop timely the i.MX' RX FIFO may run over and data
> get lost. Otherwise it's internal TX buffer may getting filled to
> a point where it runs over and data is again lost. It depends on
> the remote device how this case is handled and if it is recoverable.
>
> Obviously we want to avoid having no free buffers available. So we decrease
> the size of the buffers and increase their number and the total buffer size.
>
> Signed-off-by: Philipp Puschmann
> Reviewed-by: Lucas Stach
> ---
>
> Changelog v3:
> - enhance description
>
> Changelog v2:
> - split this patch from series "Fix UART DMA freezes for iMX6"
> - add Reviewed-by tag
>
> drivers/tty/serial/imx.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index
> 87c58f9f6390..51dc19833eab 100644
> --- a/drivers/tty/serial/imx.c
> +++ b/drivers/tty/serial/imx.c
> @@ -1034,8 +1034,6 @@ static void imx_uart_timeout(struct timer_list *t)
> }
> }
>
> -#define RX_BUF_SIZE(PAGE_SIZE)
> -
> /*
> * There are two kinds of RX DMA interrupts(such as in the MX6Q):
> * [1] the RX DMA buffer is full.
> @@ -1118,7 +1116,8 @@ static void imx_uart_dma_rx_callback(void
> *data) }
>
> /* RX DMA buffer periods */
> -#define RX_DMA_PERIODS 4
> +#define RX_DMA_PERIODS 16
> +#define RX_BUF_SIZE(PAGE_SIZE / 4)
>
Why to decrease the DMA RX buffer size here ?
The current DMA implementation support DMA cyclic mode, one SDMA BD receive one
Bluetooth frame can
bring better performance.
As you know, for L2CAP, a maximum transmission unit (MTU) associated with the
largest Baseband payload
is 341 bytes for DH5 packets.
So I suggest to increase RX_BUF_SIZE along with RX_DMA_PERIODS to feasible
value.
Andy
> static int imx_uart_start_rx_dma(struct imx_port *sport) {
> --
> 2.23.0
Re: [PATCH 4.19 00/79] 4.19.75-stable review
stable-rc/linux-4.19.y boot: 68 boots: 0 failed, 68 passed (v4.19.74-80-g42a609acc1b2) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.74-80-g42a609acc1b2/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.74-80-g42a609acc1b2/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.74-80-g42a609acc1b2 Git Commit: 42a609acc1b2b5a744dd9ad3d3eb6a71906e4bcc Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 38 unique boards, 16 SoC families, 12 builds out of 206 --- For more info write to
Re: [GIT PULL] Kbuild updates for v5.4-rc1
Hi Linus,
On Wed, Sep 18, 2019 at 3:48 AM Jessica Yu wrote:
>
> +++ Will Deacon [17/09/19 19:16 +0100]:
> >Hi Jessica,
> >
> >On Tue, Sep 17, 2019 at 08:01:36PM +0200, Jessica Yu wrote:
> >> Yikes, I did not catch Stephen Rothwell's email about pausing the
> >> linux-next releases from Sept 5 until Sept 30
> >> (https://lore.kernel.org/linux-next/20190904233443.3f73c...@canb.auug.org.au/).
> >>
> >> The modules-next namespace patches have been in since last Tuesday,
> >> and my original plan was for them to catch at least a week of
> >> linux-next time before sending the pull request. :-/ But that did not
> >> happen due to the above.
> >>
> >> So Linus, in light of the above realization, I'd say at this time - I
> >> will still formally send a pull request with the merge conflicts
> >> resolved with either solution #2 or #3, but merge at your own
> >> discretion, it's fine to delay to the following release if you're
> >> uncomfortable.
> >
> >FWIW, when I've run into unexpected merge conflicts with other trees in the
> >past, I've found that it's usually sufficient just to include the resolution
> >as an inline diff in the pull request, rather than try to munge the tree
> >with merges or rebases. Linus is pretty good at figuring it out, and with a
> >resolution to compare with, the damage is limited. The downside of the merge
> >is that it's fiddly to extract the changes and see what's actually being
> >pulled.
> >
> >Also, it's not like the kbuild stuff has been in -next for ages, so this
> >would've been a late and messy conflict regardless.
>
> Hi Will!
>
> Thanks a lot for the advice :-) The inline diff sounds like a good
> idea. This is I believe only the second tree conflict I've encountered
> so far so the tips are much appreciated.
>
> Jessica
How should we handle this?
If you pull this against the latest of your tree,
you will end up with manual merge for the following files:
scripts/link-vmlinux.sh
drivers/gpu/drm/amd/display/dc/calcs/Makefile
drivers/gpu/drm/amd/display/dc/dml/Makefile
drivers/gpu/drm/amd/display/dc/dsc/Makefile
They are solved in linux-next,
but I also double-checked it just in case.
I think the next-20190917 is correct,
but I noticed two things:
[1] linux-next modified the hashbang of scripts/link-vmlinux.sh
(/bin/sh -> /bin/bash), but this change is unneeded
[2] I fixed up drivers/gpu/drm/amd/display/dc/dcn21/Makefile too.
This is a non-obvious conflict, and not available in linux-next.
I caught it in my build testing.
I solved the merge conflicts by myself,
and I attached the diff file. (merge-diff.txt)
If you do not want to cope with those merge conflicts at all,
I will drop the three commits (8959e39272 54b8ae66ae 69a94abb82),
and I will re-send a pull request, which you will be able to pull cleanly.
I will rebase the offending 3 commits on top of your tree later.
Which do you prefer?
Please let me know your thought.
Thanks.
--
Best Regards
Masahiro Yamada
commit a3268b9f3811d651d99c474b628bd30eb2eead7b
Merge: 574cc4539762 77564a4829ef
Author: Masahiro Yamada
Date: Fri Sep 20 11:43:11 2019 +0900
Merge tag 'kbuild-v5.4' of
git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild into
merge-test
Kbuild updates for v5.4
- add modpost warn exported symbols marked as 'static' because 'static'
and EXPORT_SYMBOL is an odd combination
- break the build early if gold linker is used
- optimize the Bison rule to produce .c and .h files by a single
pattern rule
- handle PREEMPT_RT in the module vermagic and UTS_VERSION
- warn CONFIG options leaked to the user-space except existing ones
- make single targets work properly
- rebuild modules when module linker scripts are updated
- split the module final link stage into scripts/Makefile.modfinal
- fix the missed error code in merge_config.sh
- improve the error message displayed on the attempt of the O= build
in unclean source tree
- remove 'clean-dirs' syntax
- disable -Wimplicit-fallthrough warning for Clang
- add CONFIG_CC_OPTIMIZE_FOR_SIZE_O3 for ARC
- remove ARCH_{CPP,A,C}FLAGS variables
- add $(BASH) to run bash scripts
- change *CFLAGS_.o to take the relative path to $(obj)
instead of the basename
- stop suppressing Clang's -Wunused-function warnings when W=1
- fix linux/export.h to avoid genksyms calculating CRC of trimmed
exported symbols
- misc cleanups
diff --cc arch/ia64/Kconfig
index 9711cf730929,3dead116a6d7..685a3df126ca
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@@ -10,15 -10,14 +10,16 @@@ config IA6
bool
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
- select ACPI if (!IA64_HP_SIM)
- select ARCH_SUPPORTS_ACPI if (!IA64_HP_SIM)
+ select ACPI
+ select
Re: [PATCH] base: soc: Export soc_device_to_device API
On Thu 19 Sep 15:45 PDT 2019, Greg KH wrote:
> On Thu, Sep 19, 2019 at 03:40:17PM -0700, Bjorn Andersson wrote:
> > On Thu 19 Sep 15:25 PDT 2019, Greg KH wrote:
> >
> > > On Thu, Sep 19, 2019 at 03:14:56PM -0700, Bjorn Andersson wrote:
> > > > On Thu 19 Sep 14:58 PDT 2019, Greg KH wrote:
> > > >
> > > > > On Thu, Sep 19, 2019 at 02:53:00PM -0700, Bjorn Andersson wrote:
> > > > > > On Thu 19 Sep 14:32 PDT 2019, Greg KH wrote:
> > > > > >
> > > > > > > On Thu, Sep 19, 2019 at 02:13:44PM -0700, Murali Nalajala wrote:
> > > > > > > > If the soc drivers want to add custom sysfs entries it needs to
> > > > > > > > access "dev" field in "struct soc_device". This can be achieved
> > > > > > > > by "soc_device_to_device" API. Soc drivers which are built as a
> > > > > > > > module they need above API to be exported. Otherwise one can
> > > > > > > > observe compilation issues.
> > > > > > > >
> > > > > > > > Signed-off-by: Murali Nalajala
> > > > > > > > ---
> > > > > > > > drivers/base/soc.c | 1 +
> > > > > > > > 1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> > > > > > > > index 7c0c5ca..4ad52f6 100644
> > > > > > > > --- a/drivers/base/soc.c
> > > > > > > > +++ b/drivers/base/soc.c
> > > > > > > > @@ -41,6 +41,7 @@ struct device *soc_device_to_device(struct
> > > > > > > > soc_device *soc_dev)
> > > > > > > > {
> > > > > > > > return _dev->dev;
> > > > > > > > }
> > > > > > > > +EXPORT_SYMBOL_GPL(soc_device_to_device);
> > > > > > > >
> > > > > > > > static umode_t soc_attribute_mode(struct kobject *kobj,
> > > > > > > > struct attribute *attr,
> > > > > > >
> > > > > > > What in-kernel driver needs this?
> > > > > > >
> > > > > >
> > > > > > Half of the drivers interacting with the soc driver calls this API,
> > > > > > several of these I see no reason for being builtin (e.g.
> > > > > > ux500 andversatile). So I think this patch makes sense to allow us
> > > > > > to
> > > > > > build these as modules.
> > > > > >
> > > > > > > Is linux-next breaking without this?
> > > > > > >
> > > > > >
> > > > > > No, we postponed the addition of any sysfs attributes in the
> > > > > > Qualcomm
> > > > > > socinfo driver.
> > > > > >
> > > > > > > We don't export things unless we have a user of the export.
> > > > > > >
> > > > > > > Also, adding "custom" sysfs attributes is almost always not the
> > > > > > > correct
> > > > > > > thing to do at all. The driver should be doing it, by setting up
> > > > > > > the
> > > > > > > attribute group properly so that the driver core can do it
> > > > > > > automatically
> > > > > > > for it.
> > > > > > >
> > > > > > > No driver should be doing individual add/remove of sysfs files.
> > > > > > > If it
> > > > > > > does so, it is almost guaranteed to be doing it incorrectly and
> > > > > > > racing
> > > > > > > userspace.
> > > > > > >
> > > > > >
> > > > > > The problem here is that the attributes are expected to be attached
> > > > > > to
> > > > > > the soc driver, which is separate from the platform-specific
> > > > > > drivers. So
> > > > > > there's no way to do platform specific attributes the right way.
> > > > > >
> > > > > > > And yes, there's loads of in-kernel examples of doing this wrong,
> > > > > > > I've
> > > > > > > been working on fixing that up, look at the patches now in
> > > > > > > Linus's tree
> > > > > > > for platform and USB drivers that do this as examples of how to
> > > > > > > do it
> > > > > > > right.
> > > > > > >
> > > > > >
> > > > > > Agreed, this patch should not be used as an approval for any crazy
> > > > > > attributes; but it's necessary in order to extend the soc device's
> > > > > > attributes, per the current design.
> > > > >
> > > > > Wait, no, let's not let the "current design" remain if it is broken!
> > > > >
> > > > > Why can't the soc driver handle the attributes properly so that the
> > > > > individual driver doesn't have to do the create/remove?
> > > > >
> > > >
> > > > The custom attributes that these drivers want to add to the common ones
> > > > are known in advance, so I presume we could have them passed into
> > > > soc_device_register() and registered together with the common
> > > > attributes...
> > > >
> > > > It sounds like it's worth a prototype.
> > >
> > > Do you have an in-kernel example I can look at to get an idea of what is
> > > needed here?
> > >
> >
> > realview_soc_probe(), in drivers/soc/versatile/soc-realview.c,
> > implements the current mechanism of acquiring the soc's struct device
> > and then issuing a few device_create_file calls on that.
>
> That looks to be a trivial driver to fix up. Look at 6d03c140db2e
> ("USB: phy: fsl-usb: convert platform driver to use dev_groups") as an
> example of how to do this.
>
The difference between the two cases is that in the fsl-usb case it's
attributes of the device itself, while in the soc case
Re: [PATCH 1/2] soc: ti: big cleanup of Kconfig file
On 9/19/19 6:14 PM, santosh.shilim...@oracle.com wrote:
> On 9/19/19 3:33 PM, Randy Dunlap wrote:
>> From: Randy Dunlap
>>
>> Cleanup drivers/soc/ti/Kconfig:
>> - delete duplicate words
>> - end sentences with '.'
>> - fix typos/spellos
>> - Subsystem is one word
>> - capitalize acronyms
>> - reflow lines to be <= 80 columns
>>
>> Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver")
>> Fixes: 88139ed03058 ("soc: ti: add Keystone Navigator DMA support")
>> Fixes: afe761f8d3e9 ("soc: ti: Add pm33xx driver for basic suspend support")
>> Fixes: 5a99ae0092fe ("soc: ti: pm33xx: AM437X: Add rtc_only with ddr in
>> self-refresh support")
>> Fixes: a869b7b30dac ("soc: ti: Add Support for AM654 SoC config option")
>> Fixes: cff377f7897a ("soc: ti: Add Support for J721E SoC config option")
>> Signed-off-by: Randy Dunlap
>> Cc: Olof Johansson
>> Cc: Santosh Shilimkar
>> Cc: Sandeep Nair
>> Cc: Dave Gerlach
>> Cc: Keerthy
>> Cc: Tony Lindgren
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-arm-ker...@lists.infradead.org
>> ---
>> @Santosh: MAINTAINERS says that you maintain drivers/soc/ti/*,
>> but there is more that Keystone-related code in that subdirectory
>> now... just in case you want to update that info.
>>
> Yes am aware there more drivers and so far I have been taking
> care of everything in drivers/soc/ti/*
OK :)
>> drivers/soc/ti/Kconfig | 20 ++--
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
> Patch looks fine to me. Do you want me to pick this up ?
>
Yes, please.
--
~Randy
[PATCH v3 0/2] tcpm: AMS and Collision Avoidance
*** BLURB HERE *** Kyle Tso (2): usb: typec: tcpm: AMS and Collision Avoidance usb: typec: tcpm: AMS for PD2.0 drivers/usb/typec/tcpm/tcpm.c | 523 ++ include/linux/usb/pd.h| 1 + include/linux/usb/tcpm.h | 4 + 3 files changed, 468 insertions(+), 60 deletions(-) -- 2.23.0.351.gc4317032e6-goog
[PATCH v3 2/2] usb: typec: tcpm: AMS for PD2.0
AMS is defined in PD2.0 as well. Remove the filter in tcpm_ams_start
and change the CC for Collision Avoidance only if the negotiated
revision is higher than PD2.0.
Signed-off-by: Kyle Tso
---
Changelog since v2:
- N/A; This is the first version.
drivers/usb/typec/tcpm/tcpm.c | 129 +++---
1 file changed, 57 insertions(+), 72 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 7d1c30c33097..aca1c5bbe870 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -391,6 +391,12 @@ struct pd_rx_event {
struct pd_message msg;
};
+static const char * const pd_rev[] = {
+ [PD_REV10] = "rev1",
+ [PD_REV20] = "rev2",
+ [PD_REV30] = "rev3",
+};
+
#define tcpm_cc_is_sink(cc) \
((cc) == TYPEC_CC_RP_DEF || (cc) == TYPEC_CC_RP_1_5 || \
(cc) == TYPEC_CC_RP_3_0)
@@ -431,8 +437,6 @@ struct pd_rx_event {
(tcpm_port_is_sink(port) && \
((port)->cc1 == TYPEC_CC_RP_3_0 || (port)->cc2 == TYPEC_CC_RP_3_0))
-#define support_ams(port) ((port)->negotiated_rev >= PD_REV30)
-
static enum tcpm_state tcpm_default_state(struct tcpm_port *port)
{
if (port->port_type == TYPEC_PORT_DRP) {
@@ -679,14 +683,9 @@ static int tcpm_ams_finish(struct tcpm_port *port)
{
int ret = 0;
- if (!support_ams(port)) {
- port->upcoming_state = INVALID_STATE;
- return -EOPNOTSUPP;
- }
-
tcpm_log(port, "AMS %s finished", tcpm_ams_str[port->ams]);
- if (port->pwr_role == TYPEC_SOURCE)
+ if (port->negotiated_rev >= PD_REV30 && port->pwr_role == TYPEC_SOURCE)
tcpm_set_cc(port, SINK_TX_OK);
port->in_ams = false;
@@ -723,12 +722,13 @@ static int tcpm_pd_transmit(struct tcpm_port *port,
case TCPC_TX_SUCCESS:
port->message_id = (port->message_id + 1) & PD_HEADER_ID_MASK;
/*
+* USB PD rev 2.0, 8.3.2.2.1:
* USB PD rev 3.0, 8.3.2.1.3:
* "... Note that every AMS is Interruptible until the first
* Message in the sequence has been successfully sent (GoodCRC
* Message received)."
*/
- if (support_ams(port) && port->ams != NONE_AMS)
+ if (port->ams != NONE_AMS)
port->in_ams = true;
break;
case TCPC_TX_DISCARDED:
@@ -994,20 +994,18 @@ static void tcpm_set_state(struct tcpm_port *port, enum
tcpm_state state,
unsigned int delay_ms)
{
if (delay_ms) {
- tcpm_log(port, "pending state change %s -> %s @ %u ms%s%s",
+ tcpm_log(port, "pending state change %s -> %s @ %u ms [%s %s]",
tcpm_states[port->state], tcpm_states[state], delay_ms,
-support_ams(port) ? " in AMS " : "",
-support_ams(port) ? tcpm_ams_str[port->ams] : "");
+pd_rev[port->negotiated_rev], tcpm_ams_str[port->ams]);
port->delayed_state = state;
mod_delayed_work(port->wq, >state_machine,
msecs_to_jiffies(delay_ms));
port->delayed_runtime = jiffies + msecs_to_jiffies(delay_ms);
port->delay_ms = delay_ms;
} else {
- tcpm_log(port, "state change %s -> %s%s%s",
+ tcpm_log(port, "state change %s -> %s [%s %s]",
tcpm_states[port->state], tcpm_states[state],
-support_ams(port) ? " in AMS " : "",
-support_ams(port) ? tcpm_ams_str[port->ams] : "");
+pd_rev[port->negotiated_rev], tcpm_ams_str[port->ams]);
port->delayed_state = INVALID_STATE;
port->prev_state = port->state;
port->state = state;
@@ -1029,12 +1027,11 @@ static void tcpm_set_state_cond(struct tcpm_port *port,
enum tcpm_state state,
tcpm_set_state(port, state, delay_ms);
else
tcpm_log(port,
-"skipped %sstate change %s -> %s [%u ms], context
state %s%s%s",
+"skipped %sstate change %s -> %s [%u ms], context
state %s [%s %s]",
delay_ms ? "delayed " : "",
tcpm_states[port->state], tcpm_states[state],
delay_ms, tcpm_states[port->enter_state],
-support_ams(port) ? " in AMS " : "",
-support_ams(port) ? tcpm_ams_str[port->ams] : "");
+pd_rev[port->negotiated_rev], tcpm_ams_str[port->ams]);
}
static void tcpm_queue_message(struct tcpm_port *port,
@@ -1100,11 +1097,6 @@ static int tcpm_ams_start(struct tcpm_port *port, enum
tcpm_ams ams)
{
int ret = 0;
- if
[PATCH v3 1/2] usb: typec: tcpm: AMS and Collision Avoidance
This patch provides the implementation of Collision Avoidance introduced
in PD3.0. The start of each Atomic Message Sequence (AMS) initiated by
the port will be denied if the current AMS is not interruptible. The
Source port will set the CC to SinkTxNG if it is going to initiate an
AMS, and SinkTxOk otherwise. Meanwhile, any AMS initiated by a Sink port
will be denied in TCPM if the port partner (Source) sets SinkTxNG except
for HARD_RESET and SOFT_RESET.
Signed-off-by: Kyle Tso
---
Changelog since v2:
- (nit) changed some return values from constant 0 to variable "ret" in
function tcpm_ams_start
drivers/usb/typec/tcpm/tcpm.c | 538 ++
include/linux/usb/pd.h| 1 +
include/linux/usb/tcpm.h | 4 +
3 files changed, 483 insertions(+), 60 deletions(-)
diff --git a/drivers/usb/typec/tcpm/tcpm.c b/drivers/usb/typec/tcpm/tcpm.c
index 96562744101c..7d1c30c33097 100644
--- a/drivers/usb/typec/tcpm/tcpm.c
+++ b/drivers/usb/typec/tcpm/tcpm.c
@@ -73,6 +73,8 @@
S(SNK_HARD_RESET_SINK_ON), \
\
S(SOFT_RESET), \
+ S(SRC_SOFT_RESET_WAIT_SNK_TX), \
+ S(SNK_SOFT_RESET), \
S(SOFT_RESET_SEND), \
\
S(DR_SWAP_ACCEPT), \
@@ -126,7 +128,45 @@
\
S(ERROR_RECOVERY), \
S(PORT_RESET), \
- S(PORT_RESET_WAIT_OFF)
+ S(PORT_RESET_WAIT_OFF), \
+ \
+ S(AMS_START)
+
+#define FOREACH_AMS(S) \
+ S(NONE_AMS),\
+ S(POWER_NEGOTIATION), \
+ S(GOTOMIN), \
+ S(SOFT_RESET_AMS), \
+ S(HARD_RESET), \
+ S(CABLE_RESET), \
+ S(GET_SOURCE_CAPABILITIES), \
+ S(GET_SINK_CAPABILITIES), \
+ S(POWER_ROLE_SWAP), \
+ S(FAST_ROLE_SWAP), \
+ S(DATA_ROLE_SWAP), \
+ S(VCONN_SWAP), \
+ S(SOURCE_ALERT),\
+ S(GETTING_SOURCE_EXTENDED_CAPABILITIES),\
+ S(GETTING_SOURCE_SINK_STATUS), \
+ S(GETTING_BATTERY_CAPABILITIES),\
+ S(GETTING_BATTERY_STATUS), \
+ S(GETTING_MANUFACTURER_INFORMATION),\
+ S(SECURITY),\
+ S(FIRMWARE_UPDATE), \
+ S(DISCOVER_IDENTITY), \
+ S(SOURCE_STARTUP_CABLE_PLUG_DISCOVER_IDENTITY), \
+ S(DISCOVER_SVIDS), \
+ S(DISCOVER_MODES), \
+ S(DFP_TO_UFP_ENTER_MODE), \
+ S(DFP_TO_UFP_EXIT_MODE),\
+ S(DFP_TO_CABLE_PLUG_ENTER_MODE),\
+ S(DFP_TO_CABLE_PLUG_EXIT_MODE), \
+ S(ATTENTION), \
+ S(BIST),\
+ S(UNSTRUCTURED_VDMS), \
+ S(STRUCTURED_VDMS), \
+ S(COUNTRY_INFO),\
+ S(COUNTRY_CODES)
#define GENERATE_ENUM(e) e
#define GENERATE_STRING(s) #s
@@ -139,6 +179,14 @@ static const char * const tcpm_states[] = {
FOREACH_STATE(GENERATE_STRING)
};
+enum tcpm_ams {
+ FOREACH_AMS(GENERATE_ENUM)
+};
+
+static const char * const tcpm_ams_str[] = {
+ FOREACH_AMS(GENERATE_STRING)
+};
+
enum vdm_states {
VDM_STATE_ERR_BUSY = -3,
VDM_STATE_ERR_SEND = -2,
@@ -148,6 +196,7 @@ enum vdm_states {
VDM_STATE_READY = 1,
VDM_STATE_BUSY = 2,
VDM_STATE_WAIT_RSP_BUSY = 3,
+ VDM_STATE_SEND_MESSAGE = 4,
};
enum pd_msg_request {
@@ -322,6 +371,11 @@ struct tcpm_port {
/* port belongs to a self powered device */
bool self_powered;
+ /* Collision Avoidance and Atomic Message Sequence */
+ enum tcpm_state upcoming_state;
+ enum tcpm_ams ams;
+ bool in_ams;
+
#ifdef CONFIG_DEBUG_FS
struct dentry *dentry;
struct mutex logbuffer_lock;/* log buffer access lock */
@@ -373,6 +427,12 @@ struct pd_rx_event {
((port)->try_src_count == 0 && (port)->try_role == TYPEC_SOURCE && \
(port)->port_type == TYPEC_PORT_DRP)
+#define tcpm_sink_tx_ok(port) \
+ (tcpm_port_is_sink(port) && \
+ ((port)->cc1 == TYPEC_CC_RP_3_0 || (port)->cc2 == TYPEC_CC_RP_3_0))
+
+#define support_ams(port) ((port)->negotiated_rev >= PD_REV30)
+
static enum tcpm_state tcpm_default_state(struct tcpm_port *port)
{
if (port->port_type == TYPEC_PORT_DRP) {
@@ -608,6
drivers/platform/x86/asus-wmi.c:464: undefined reference to `battery_hook_unregister'
Hi Kristian,
FYI, the error/warning still remains.
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 574cc4539762561d96b456dbc0544d8898bd4c6e
commit: 7973353e92ee1e7ca3b2eb361a4b7cb66c92abee platform/x86: asus-wmi:
Refactor charge threshold to use the battery hooking API
date: 10 days ago
config: x86_64-randconfig-e001-201937 (attached as .config)
compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
reproduce:
git checkout 7973353e92ee1e7ca3b2eb361a4b7cb66c92abee
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
ld: drivers/platform/x86/asus-wmi.o: in function `asus_wmi_battery_exit':
>> drivers/platform/x86/asus-wmi.c:464: undefined reference to
>> `battery_hook_unregister'
ld: drivers/platform/x86/asus-wmi.o: in function `asus_wmi_battery_init':
>> drivers/platform/x86/asus-wmi.c:457: undefined reference to
>> `battery_hook_register'
vim +464 drivers/platform/x86/asus-wmi.c
451
452 static void asus_wmi_battery_init(struct asus_wmi *asus)
453 {
454 asus->battery_rsoc_available = false;
455 if (asus_wmi_dev_is_present(asus, ASUS_WMI_DEVID_RSOC)) {
456 asus->battery_rsoc_available = true;
> 457 battery_hook_register(_hook);
458 }
459 }
460
461 static void asus_wmi_battery_exit(struct asus_wmi *asus)
462 {
463 if (asus->battery_rsoc_available)
> 464 battery_hook_unregister(_hook);
465 }
466
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [PATCH 4.14 00/59] 4.14.146-stable review
stable-rc/linux-4.14.y boot: 65 boots: 0 failed, 65 passed (v4.14.145-60-g981030d9563c) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.14.y/kernel/v4.14.145-60-g981030d9563c/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.14.y/kernel/v4.14.145-60-g981030d9563c/ Tree: stable-rc Branch: linux-4.14.y Git Describe: v4.14.145-60-g981030d9563c Git Commit: 981030d9563ce66bc738ff8fee0ed8c81922904b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 32 unique boards, 15 SoC families, 10 builds out of 201 --- For more info write to
Re: [PATCH 4.9 00/74] 4.9.194-stable review
stable-rc/linux-4.9.y boot: 54 boots: 0 failed, 54 passed (v4.9.193-75-gfebb363e252b) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.9.y/kernel/v4.9.193-75-gfebb363e252b/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.9.y/kernel/v4.9.193-75-gfebb363e252b/ Tree: stable-rc Branch: linux-4.9.y Git Describe: v4.9.193-75-gfebb363e252b Git Commit: febb363e252bd50629d7efc675ba30286a33f209 Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 24 unique boards, 14 SoC families, 10 builds out of 197 --- For more info write to
Re: [PATCH -next] PCI: tegra: Add missing include file
On 9/20/2019 7:18 AM, YueHaibing wrote:
Fix build error without CONFIG_PINCTRL
drivers/pci/controller/dwc/pcie-tegra194.c: In function tegra_pcie_config_rp:
drivers/pci/controller/dwc/pcie-tegra194.c:1394:8: error: implicit declaration
of function pinctrl_pm_select_default_state;
did you mean prandom_seed_full_state? [-Werror=implicit-function-declaration]
ret = pinctrl_pm_select_default_state(dev);
^~~
prandom_seed_full_state
Reported-by: Hulk Robot
Fixes: ab2a50e7602b ("PCI: tegra: Add support to configure sideband pins")
Signed-off-by: YueHaibing
---
drivers/pci/controller/dwc/pcie-tegra194.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
b/drivers/pci/controller/dwc/pcie-tegra194.c
index 09ed8e4..b219d3b2 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "pcie-designware.h"
#include
#include
Thanks for pushing this change.
Reviewed-by: Vidya Sagar
Re: [PATCH] sched/fair: Speed-up energy-aware wake-ups
Hi Quentin,
On Thu, Sep 12, 2019 at 11:44:04AM +0200, Quentin Perret wrote:
> From: Quentin Perret
>
> EAS computes the energy impact of migrating a waking task when deciding
> on which CPU it should run. However, the current approach is known to
> have a high algorithmic complexity, which can result in prohibitively
> high wake-up latencies on systems with complex energy models, such as
> systems with per-CPU DVFS. On such systems, the algorithm complexity is
> in O(n^2) (ignoring the cost of searching for performance states in the
> EM) with 'n' the number of CPUs.
>
> To address this, re-factor the EAS wake-up path to compute the energy
> 'delta' (with and without the task) on a per-performance domain basis,
> rather than system-wide, which brings the complexity down to O(n).
>
> No functional changes intended.
>
> Signed-off-by: Quentin Perret
>
[snip]
> /*
> @@ -6381,21 +6367,19 @@ compute_energy(struct task_struct *p, int dst_cpu,
> struct perf_domain *pd)
> * other use-cases too. So, until someone finds a better way to solve this,
> * let's keep things simple by re-using the existing slow path.
> */
> -
> static int find_energy_efficient_cpu(struct task_struct *p, int prev_cpu)
> {
> - unsigned long prev_energy = ULONG_MAX, best_energy = ULONG_MAX;
> + unsigned long prev_delta = ULONG_MAX, best_delta = ULONG_MAX;
> struct root_domain *rd = cpu_rq(smp_processor_id())->rd;
> + unsigned long cpu_cap, util, base_energy = 0;
> int cpu, best_energy_cpu = prev_cpu;
> - struct perf_domain *head, *pd;
> - unsigned long cpu_cap, util;
> struct sched_domain *sd;
> + struct perf_domain *pd;
>
> rcu_read_lock();
> pd = rcu_dereference(rd->pd);
> if (!pd || READ_ONCE(rd->overutilized))
> goto fail;
> - head = pd;
>
> /*
>* Energy-aware wake-up happens on the lowest sched_domain starting
> @@ -6412,9 +6396,14 @@ static int find_energy_efficient_cpu(struct
> task_struct *p, int prev_cpu)
> goto unlock;
>
> for (; pd; pd = pd->next) {
> - unsigned long cur_energy, spare_cap, max_spare_cap = 0;
> + unsigned long cur_delta, spare_cap, max_spare_cap = 0;
> + unsigned long base_energy_pd;
> int max_spare_cap_cpu = -1;
>
> + /* Compute the 'base' energy of the pd, without @p */
> + base_energy_pd = compute_energy(p, -1, pd);
> + base_energy += base_energy_pd;
> +
> for_each_cpu_and(cpu, perf_domain_span(pd),
> sched_domain_span(sd)) {
> if (!cpumask_test_cpu(cpu, p->cpus_ptr))
> continue;
> @@ -6427,9 +6416,9 @@ static int find_energy_efficient_cpu(struct task_struct
> *p, int prev_cpu)
>
> /* Always use prev_cpu as a candidate. */
> if (cpu == prev_cpu) {
> - prev_energy = compute_energy(p, prev_cpu, head);
> - best_energy = min(best_energy, prev_energy);
> - continue;
> + prev_delta = compute_energy(p, prev_cpu, pd);
> + prev_delta -= base_energy_pd;
> + best_delta = min(best_delta, prev_delta);
> }
Earlier, we are not checking the spare capacity for the prev_cpu. Now that the
continue statement is removed, prev_cpu could also be the max_spare_cap_cpu.
Actually that makes sense. Because there is no reason why we want to select
another CPU which has less spare capacity than previous CPU.
Is this behavior intentional?
When prev_cpu == max_spare_cap_cpu, we are evaluating the energy again for the
same CPU below. That could have been skipped by returning prev_cpu when
prev_cpu == max_spare_cap_cpu.
>
> /*
> @@ -6445,9 +6434,10 @@ static int find_energy_efficient_cpu(struct
> task_struct *p, int prev_cpu)
>
> /* Evaluate the energy impact of using this CPU. */
> if (max_spare_cap_cpu >= 0) {
> - cur_energy = compute_energy(p, max_spare_cap_cpu, head);
> - if (cur_energy < best_energy) {
> - best_energy = cur_energy;
> + cur_delta = compute_energy(p, max_spare_cap_cpu, pd);
> + cur_delta -= base_energy_pd;
> + if (cur_delta < best_delta) {
> + best_delta = cur_delta;
> best_energy_cpu = max_spare_cap_cpu;
> }
> }
> @@ -6459,10 +6449,10 @@ static int find_energy_efficient_cpu(struct
> task_struct *p, int prev_cpu)
>* Pick the best CPU if prev_cpu cannot be used, or if it saves at
>* least 6% of the energy used by prev_cpu.
>*/
> - if (prev_energy == ULONG_MAX)
> + if (prev_delta == ULONG_MAX)
>
[PATCH] rtl8xxxu: prevent leaking urb
In rtl8xxxu_submit_int_urb if usb_submit_urb fails the allocated urb
should be released.
Signed-off-by: Navid Emamdoost
---
drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
index 8136e268b4e6..4a559c37e208 100644
--- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
+++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
@@ -5443,6 +5443,7 @@ static int rtl8xxxu_submit_int_urb(struct ieee80211_hw
*hw)
ret = usb_submit_urb(urb, GFP_KERNEL);
if (ret) {
usb_unanchor_urb(urb);
+ usb_free_urb(urb);
goto error;
}
--
2.17.1
Re: [PATCH] tty:vt: Add check the return value of kzalloc to avoid oops
On Thu, 19 Sep 2019, Greg KH wrote:
> On Thu, Sep 19, 2019 at 05:18:15PM +0800, Xiaoming Ni wrote:
> > Using kzalloc() to allocate memory in function con_init(), but not
> > checking the return value, there is a risk of null pointer references
> > oops.
> >
> > Signed-off-by: Xiaoming Ni
>
> We keep having this be "reported" :(
Something probably needs to be "communicated" about that.
> > vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
> > GFP_NOWAIT);
> > + if (unlikely(!vc)) {
> > + pr_warn("%s:failed to allocate memory for the %u vc\n",
> > + __func__, currcons);
> > + break;
> > + }
>
> At init, this really can not happen. Have you see it ever happen?
This is maybe too subtle a fact. The "communication" could be done with
some GFP_WONTFAIL flag, and have the allocator simply pannic() if it
ever fails.
Nicolas
[PATCH] staging: rtl8192u: fix multiple memory leaks on error path
In rtl8192_tx on error handling path allocated urbs and also skb should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/staging/rtl8192u/r8192U_core.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index fe1f279ca368..b62b03802b1b 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1422,7 +1422,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
(struct tx_fwinfo_819x_usb *)(skb->data +
USB_HWDESC_HEADER_LEN);
struct usb_device *udev = priv->udev;
int pend;
- int status;
+ int status, rt = -1;
struct urb *tx_urb = NULL, *tx_urb_zero = NULL;
unsigned int idx_pipe;
@@ -1566,8 +1566,10 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
}
if (bSend0Byte) {
tx_urb_zero = usb_alloc_urb(0, GFP_ATOMIC);
- if (!tx_urb_zero)
- return -ENOMEM;
+ if (!tx_urb_zero) {
+ rt = -ENOMEM;
+ goto error;
+ }
usb_fill_bulk_urb(tx_urb_zero, udev,
usb_sndbulkpipe(udev, idx_pipe),
, 0, tx_zero_isr, dev);
@@ -1577,7 +1579,7 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
"Error TX URB for zero byte %d, error
%d",
atomic_read(>tx_pending[tcb_desc->queue_index]),
status);
- return -1;
+ goto error;
}
}
netif_trans_update(dev);
@@ -1588,7 +1590,12 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff
*skb)
RT_TRACE(COMP_ERR, "Error TX URB %d, error %d",
atomic_read(>tx_pending[tcb_desc->queue_index]),
status);
- return -1;
+
+error:
+ dev_kfree_skb_any(skb);
+ usb_free_urb(tx_urb);
+ usb_free_urb(tx_urb_zero);
+ return rt;
}
static short rtl8192_usb_initendpoints(struct net_device *dev)
--
2.17.1
Re: [PATCH 1/1] powerpc: kvm: Reduce calls to get current->mm by storing the value locally
Hello Paul,
I sent this patch, but I have a question:
On Thu, 2019-09-19 at 19:27 -0300, Leonardo Bras wrote:
> Reduces the number of calls to get_current() in order to get the value of
> current->mm by doing it once and storing the value, since it is not
> supposed to change inside the same process).
>
> Signed-off-by: Leonardo Bras
> ---
> arch/powerpc/kvm/book3s_64_mmu_hv.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> index 9a75f0e1933b..f2b9aea43216 100644
> --- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
> +++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
> @@ -508,6 +508,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> struct vm_area_struct *vma;
> unsigned long rcbits;
> long mmio_update;
> + struct mm_struct *mm;
>
> if (kvm_is_radix(kvm))
> return kvmppc_book3s_radix_page_fault(run, vcpu, ea, dsisr);
> @@ -584,6 +585,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> is_ci = false;
> pfn = 0;
> page = NULL;
> + mm = current->mm;
Here, current->mm is not always the same as kvm->mm?
> pte_size = PAGE_SIZE;
> writing = (dsisr & DSISR_ISSTORE) != 0;
> /* If writing != 0, then the HPTE must allow writing, if we get here */
> @@ -592,8 +594,8 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> npages = get_user_pages_fast(hva, 1, writing ? FOLL_WRITE : 0, pages);
> if (npages < 1) {
> /* Check if it's an I/O mapping */
> - down_read(>mm->mmap_sem);
> - vma = find_vma(current->mm, hva);
> + down_read(>mmap_sem);
> + vma = find_vma(mm, hva);
> if (vma && vma->vm_start <= hva && hva + psize <= vma->vm_end &&
> (vma->vm_flags & VM_PFNMAP)) {
> pfn = vma->vm_pgoff +
> @@ -602,7 +604,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
> is_ci = pte_ci(__pte((pgprot_val(vma->vm_page_prot;
> write_ok = vma->vm_flags & VM_WRITE;
> }
> - up_read(>mm->mmap_sem);
> + up_read(>mmap_sem);
> if (!pfn)
> goto out_put;
> } else {
> @@ -621,8 +623,7 @@ int kvmppc_book3s_hv_page_fault(struct kvm_run *run,
> struct kvm_vcpu *vcpu,
>* hugepage split and collapse.
>*/
> local_irq_save(flags);
> - ptep = find_current_mm_pte(current->mm->pgd,
> -hva, NULL, NULL);
> + ptep = find_current_mm_pte(mm->pgd, hva, NULL, NULL);
> if (ptep) {
> pte = kvmppc_read_update_linux_pte(ptep, 1);
> if (__pte_write(pte))
Thanks !
signature.asc
Description: This is a digitally signed message part
Re: [PATCH v2 2/2] reset: Reset controller driver for Intel LGM SoC
Hi Martin,
On 9/20/2019 3:51 AM, Martin Blumenstingl wrote:
Hi Dilip,
(sorry for the late reply)
On Thu, Sep 12, 2019 at 8:38 AM Dilip Kota wrote:
[...]
The major difference between the vrx200 and lgm is:
1.) RCU in vrx200 is having multiple register regions wheres RCU in lgm
has one single register region.
2.) Register offsets and bit offsets are different.
So enhancing the intel-reset-syscon.c to provide compatibility/support
for vrx200.
Please check the below dtsi binding proposal and let me know your view.
rcu0:reset-controller@ {
compatible= "intel,rcu-lgm";
reg = <0x000 0x8>, , ,
;
I'm not sure that I understand what are reg_set2/3/4 for
the first resource (0x8 at 0x0) already covers the whole LGM RCU,
so what is the purpose of the other register resources
Yes, as you said the first register resource is enough for LGM RCU as
registers are at one single region. Whereas in older SoCs RCU registers
are at different regions, so for that reason reg_set2/3/4 are used.
Driver will decide in reading the no. of register resources based on the
"struct of_device_id".
Regards,
Dilip
intel,global-reset = <0x10 30>;
#reset-cells = <3>;
};
"#reset-cells":
const:3
description: |
The 1st cell is the reset register offset.
The 2nd cell is the reset set bit offset.
The 3rd cell is the reset status bit offset.
I think this will work fine for VRX200 (and even older SoCs)
as you have described in your previous emails we can determine the
status offset from the reset offset using a simple if/else
for LGM I like your initial suggestion with #reset-cells = <2> because
it's easier to read and write.
Reset driver takes care of parsing the register address "reg" as per the
".data" structure in struct of_device_id.
Reset driver takes care of traversing the status register offset.
the differentiation between two and three #reset-cells can also happen
based on the struct of_device_id:
- the LGM implementation would simply also use the reset bit as status
bit (only two cells are needed)
- the implementation for earlier SoCs would parse the third cell and
use that as status bit
Philipp, can you please share your opinion on how to move forward with
the reset-intel driver from this series?
The reset_control_ops from the reset-intel driver are (in my opinion)
a bug-fixed and improved version of what we already have in
drivers/reset/reset-lantiq.c. The driver is NOT simply copy and paste
because the register layout was greatly simplified for the newer SoCs
(for which there is reset-intel) compared to the older ones
(reset-lantiq).
Dilip's suggestion (in my own words) is that you take his new
reset-intel driver, then we will work on porting reset-lantiq over to
that so in the end we can drop the reset-lantiq driver. This approach
means more work for me (as I am probably the one who then has to do
the work to port reset-lantiq over to reset-intel). I'm happy to do
that work if you think that it's worth following this approach.
So I want your opinion on this before I spend any effort on porting
reset-lantiq over to reset-intel.
Martin
Re: [RFC {net,iproute2}-next 0/2] Introduce an eBPF hookpoint for tx queue selection in the XPS (Transmit Packet Steering) code.
On Thu, Sep 19, 2019 at 6:42 PM Jason Wang wrote: > > > On 2019/9/20 上午8:05, Matt Cover wrote: > > On Thu, Sep 19, 2019 at 3:45 PM Matthew Cover wrote: > >> WORK IN PROGRESS: > >>* bpf program loading works! > >>* txq steering via bpf program return code works! > >>* bpf program unloading not working. > >>* bpf program attached query not working. > >> > >> This patch set provides a bpf hookpoint with goals similar to, but a more > >> generic implementation than, TUNSETSTEERINGEBPF; userspace supplied tx > >> queue > >> selection policy. > > > One point that I introduce TUNSETSTEERINGEBPF instead of using a generic > way like cls/act bpf is that I need make sure to have a consistent API > with macvtap. > > In the case of macvtap, TX means transmit from userspace to kernel, but > for TUN, it means transmit from kernel to userspace. > Ah, ok. I'll have to check that out at some point. > > >> > >> TUNSETSTEERINGEBPF is a useful bpf hookpoint, but has some drawbacks. > >> > >> First, it only works on tun/tap devices. > >> > >> Second, there is no way in the current TUNSETSTEERINGEBPF implementation > >> to bail out or load a noop bpf prog and fallback to the no prog tx queue > >> selection method. > > > I believe it expect that eBPF should take all the parts (even the > fallback part). > This would be easy to change in the existing TUNSETSTEERINGEBPF implementation if desired. We'd just need a negative return from the bpf prog to result in falling back to tun_automq_select_queue(). If that behavior sounds reasonable to you, I can look into that as a separate patch. > > >> > >> Third, the TUNSETSTEERINGEBPF interface seems to require possession of > >> existing > >> or creation of new queues/fds. > > > That's the way TUN work for past +10 years because ioctl is the only way > to do configuration and it requires a fd to carry that. David suggest to > implement netlink but nobody did that. > I see. > > >> > >> This most naturally fits in the "wire" implementation since possession of > >> fds > >> is ensured. However, it also means the various "wire" implementations (e.g. > >> qemu) have to all be made aware of TUNSETSTEERINGEBPF and expose an > >> interface > >> to load/unload a bpf prog (or provide a mechanism to pass an fd to another > >> program). > > > The load/unload of ebpf program is standard bpf() syscall. Ioctl just > attach that to TUN. This idea is borrowed from packet socket which the > bpf program was attached through setsockopt(). > Yeah, it doesn't take much code to load a prog. I wrote one earlier this week in fact which spins up an extra fd and detaches right after. > > >> > >> Alternatively, you can spin up an extra queue and immediately disable via > >> IFF_DETACH_QUEUE, but this seems unsafe; packets could be enqueued to this > >> extra file descriptor which is part of our bpf prog loader, not our "wire". > > > You can use you 'wire' queue to do ioctl, but we can invent other API. > It might be cool to provide a way to create an already detached fd (not sure if this is non-trivial for some reason). Switching over to netlink could be the more long term goal. > > >> > >> Placing this in the XPS code and leveraging iproute2 and rtnetlink to > >> provide > >> our bpf prog loader in a similar manner to xdp gives us a nice way to > >> separate > >> the tap "wire" and the loading of tx queue selection policy. It also lets > >> us > >> use this hookpoint for any device traversing XPS. > >> > >> This patch only introduces the new hookpoint to the XPS code and will not > >> yet > >> be used by tun/tap devices using the intree tun.ko (which implements an > >> .ndo_select_queue and does not traverse the XPS code). > >> > >> In a future patch set, we can optionally refactor tun.ko to traverse this > >> call > >> to bpf_prog_run_clear_cb() and bpf prog storage. tun/tap devices could then > >> leverage iproute2 as a generic loader. The TUNSETSTEERINGEBPF interface > >> could > >> at this point be optionally deprecated/removed. > > > As described above, we need it for macvtap and you propose here can not > work for that. > > I'm not against this proposal, just want to clarify some considerations > when developing TUNSETSTEERINGEPF. The main goal is for VM to implement > sophisticated steering policy like RSS without touching kernel. > Very cool. Thank you for your comments Jason; they have added clarity to some things. I'm still interested in adding this hookpoint, community willing. I believe it provides value beyond xps_cpus/xps_rxqs. I also plan to look into adding a similar hookpoint in the rps code. That will unlock additional possibilities for this xps hookpoint (e.g. rfs implemented via bpf maps, but only on a subset of traffic [high priority or especially resource costly] rather than all). I've had (so far casual) chats with a couple NIC vendors about various "SmartNICs" supporting custom entropy fields for RSS. I'm playing with the idea of an "rpsoffload"
[PATCH] can: gs_usb: prevent memory leak
In gs_can_open if usb_submit_urb fails the allocated urb should be released. Signed-off-by: Navid Emamdoost --- drivers/net/can/usb/gs_usb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/net/can/usb/gs_usb.c b/drivers/net/can/usb/gs_usb.c index bd6eb9967630..2f74f6704c12 100644 --- a/drivers/net/can/usb/gs_usb.c +++ b/drivers/net/can/usb/gs_usb.c @@ -623,6 +623,7 @@ static int gs_can_open(struct net_device *netdev) rc); usb_unanchor_urb(urb); + usb_free_urb(urb); break; } -- 2.17.1
RE: [EXT] [PATCH v4 0/3] Fix UART DMA freezes for i.MX SOCs
From: Philipp Puschmann Sent: Thursday, September 19, 2019 10:30 PM > For some years and since many kernel versions there are reports that RX > UART DMA channel stops working at one point. So far the usual workaround > was to disable RX DMA. This patches fix the underlying problem. > > When a running sdma script does not find any usable destination buffer to put > its data into it just leads to stopping the channel being scheduled again. As > solution we manually retrigger the sdma script for this channel and by this > dissolve the freeze. > > While this seems to work fine so far, it may come to buffer overruns when the > channel - even temporary - is stopped. This case has to be addressed by > device drivers by increasing the number of DMA periods. > > This patch series was tested with the current kernel and backported to kernel > 4.15 with a special use case using a WL1837MOD via UART and provoking the > hanging of UART RX DMA within seconds after starting a test application. It > resulted in well known > "Bluetooth: hci0: command 0x0408 tx timeout" > errors and complete stop of UART data reception. Our Bluetooth traffic > consists of many independent small packets, mostly only a few bytes, causing > high usage of periods. > > Changelog v4: > - fixed the fixes tags > > Changelog v3: > - fixes typo in dma_wmb > - add fixes tags > > Changelog v2: > - adapt title (this patches are not only for i.MX6) > - improve some comments and patch descriptions > - add a dma_wb() around BD_DONE flag > - add Reviewed-by tags > - split off "serial: imx: adapt rx buffer and dma periods" > > Philipp Puschmann (3): > dmaengine: imx-sdma: fix buffer ownership > dmaengine: imx-sdma: fix dma freezes > dmaengine: imx-sdma: drop redundant variable > > drivers/dma/imx-sdma.c | 32 ++-- > 1 file changed, 22 insertions(+), 10 deletions(-) > > -- > 2.23.0 The patch set look fine that is really to fix some corner issue from the logical view. Reviewed-by: Fugang Duan
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/20 上午10:16, Tiwei Bie wrote:
On Fri, Sep 20, 2019 at 09:30:58AM +0800, Jason Wang wrote:
On 2019/9/19 下午11:45, Tiwei Bie wrote:
On Thu, Sep 19, 2019 at 09:08:11PM +0800, Jason Wang wrote:
On 2019/9/18 下午10:32, Michael S. Tsirkin wrote:
So I have some questions:
1) Compared to method 2, what's the advantage of creating a new vhost char
device? I guess it's for keep the API compatibility?
One benefit is that we can avoid doing vhost ioctls on
VFIO device fd.
Yes, but any benefit from doing this?
It does seem a bit more modular, but it's certainly not a big deal.
Ok, if we go this way, it could be as simple as provide some callback to
vhost, then vhost can just forward the ioctl through parent_ops.
2) For method 2, is there any easy way for user/admin to distinguish e.g
ordinary vfio-mdev for vhost from ordinary vfio-mdev?
I think device-api could be a choice.
Ok.
I saw you introduce
ops matching helper but it's not friendly to management.
The ops matching helper is just to check whether a given
vfio-device is based on a mdev device.
3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
assumes the parameter comes from userspace, it prevents support kernel
virtio drivers.
4) So comes the idea of method 3, since it register a new vhost-mdev driver,
we can use device specific ops instead of VFIO ones, then we can have a
common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
As the above draft shows, this requires introducing a new
VFIO device driver. I think Alex's opinion matters here.
Just to clarify, a new type of mdev driver but provides dummy
vfio_device_ops for VFIO to make container DMA ioctl work.
I see. Thanks! IIUC, you mean we can provide a very tiny
VFIO device driver in drivers/vhost/mdev.c, e.g.:
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
module_put(THIS_MODULE);
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release= vfio_vhost_mdev_release,
};
static int vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
... Check the mdev device_id proposed in ...
... https://lkml.org/lkml/2019/9/12/151 ...
To clarify, this should be done through the id_table fields in
vhost_mdev_driver, and it should claim it supports virtio-mdev device only:
static struct mdev_class_id id_table[] = {
{ MDEV_ID_VIRTIO },
{ 0 },
};
static struct mdev_driver vhost_mdev_driver = {
...
.id_table = id_table,
}
In this way, both of virtio-mdev and vhost-mdev will try to
take this device. We may want a way to let vhost-mdev take this
device only when users explicitly ask it to do it. Or maybe we
can have a different MDEV_ID for vhost-mdev but share the device
ops with virtio-mdev.
I think it's similar to virtio-pci vs vfio-pci. User can choose to
switch the driver through bind/unbind.
return vfio_add_group_dev(dev, _vhost_mdev_dev_ops, mdev);
And in vfio_vhost_mdev_ops, all its need is to just implement vhost-net
ioctl and translate them to virtio-mdev transport (e.g device_ops I proposed
or ioctls other whatever other method) API.
I see, so my previous understanding is basically correct:
https://lkml.org/lkml/2019/9/17/332
I.e. we won't have a separate vhost fd and we will do all vhost
ioctls on the VFIO device fd backed by this new VFIO driver.
Yes.
Thanks
And it could have a dummy ops
implementation for the other device_ops.
}
static void vhost_mdev_remove(struct device *dev)
{
vfio_del_group_dev(dev);
}
static struct mdev_driver vhost_mdev_driver = {
.name = "vhost_mdev",
.probe = vhost_mdev_probe,
.remove = vhost_mdev_remove,
};
So we can bind above mdev driver to the virtio-mdev compatible
mdev devices when we want to use vhost-mdev.
After binding above driver to the mdev device, we can setup IOMMU
via VFIO and get VFIO device fd of this mdev device, and pass it
to vhost fd (/dev/vhost-mdev) with a SET_BACKEND ioctl.
Then what vhost-mdev char device did is just forwarding ioctl back to this
vfio device fd which seems a overkill. It's simpler that just do ioctl on
the device ops directly.
Yes.
Thanks,
Tiwei
Thanks
Thanks,
Tiwei
Thanks
Yes, it is.
Thanks
[PATCH v3] HID: hidraw: replace printk() with corresponding pr_xx() variant
This commit replaces direct invocations of printk with
their appropriate pr_info/warn() variant.
Signed-off-by: Rishi Gupta
---
Changes in v3:
* Use hid_warn() subsystem specific variant instead of pr_warn()
drivers/hid/hidraw.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/hid/hidraw.c b/drivers/hid/hidraw.c
index 006bd6f..a42f4b5 100644
--- a/drivers/hid/hidraw.c
+++ b/drivers/hid/hidraw.c
@@ -197,15 +197,15 @@ static ssize_t hidraw_get_report(struct file *file, char
__user *buffer, size_t
}
if (count > HID_MAX_BUFFER_SIZE) {
- printk(KERN_WARNING "hidraw: pid %d passed too large report\n",
- task_pid_nr(current));
+ hid_warn(dev, "pid %d passed too large report\n",
+ task_pid_nr(current));
ret = -EINVAL;
goto out;
}
if (count < 2) {
- printk(KERN_WARNING "hidraw: pid %d passed too short report\n",
- task_pid_nr(current));
+ hid_warn(dev, "pid %d passed too short report\n",
+ task_pid_nr(current));
ret = -EINVAL;
goto out;
}
@@ -597,7 +597,7 @@ int __init hidraw_init(void)
if (result < 0)
goto error_class;
- printk(KERN_INFO "hidraw: raw HID events driver (C) Jiri Kosina\n");
+ pr_info("raw HID events driver (C) Jiri Kosina\n");
out:
return result;
--
2.7.4
RE: [PATCH] tty:vt: Add check the return value of kzalloc to avoid oops
On 2019/9/19 17:30, Greg KH wrote:
> On Thu, Sep 19, 2019 at 05:18:15PM +0800, Xiaoming Ni wrote:
>> Using kzalloc() to allocate memory in function con_init(), but not
>> checking the return value, there is a risk of null pointer references
>> oops.
>>
>> Signed-off-by: Xiaoming Ni
>
> We keep having this be "reported"
>
>> ---
>> drivers/tty/vt/vt.c | 18 ++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
>> index 34aa39d..db83e52 100644
>> --- a/drivers/tty/vt/vt.c
>> +++ b/drivers/tty/vt/vt.c
>> @@ -3357,15 +3357,33 @@ static int __init con_init(void)
>>
>> for (currcons = 0; currcons < MIN_NR_CONSOLES; currcons++) {
>> vc_cons[currcons].d = vc = kzalloc(sizeof(struct vc_data),
>> GFP_NOWAIT);
>> +if (unlikely(!vc)) {
>> +pr_warn("%s:failed to allocate memory for the %u vc\n",
>> +__func__, currcons);
>> +break;
>> +}
>
> At init, this really can not happen. Have you see it ever happen?
I did not actually observe the null pointer here.
I am confused when I see the code allocated here without check the return value.
Small memory allocation failures are difficult to occur during system
initialization
But is it not safe enough if the code is not judged?
Also if the memory allocation failure is not allowed here, is it better to add
the __GFP_NOFAIL flags?
>> INIT_WORK(_cons[currcons].SAK_work, vc_SAK);
>> tty_port_init(>port);
>> visual_init(vc, currcons, 1);
>> vc->vc_screenbuf = kzalloc(vc->vc_screenbuf_size, GFP_NOWAIT);
>> +if (unlikely(!vc->vc_screenbuf)) {
>
> Never use likely/unlikely unless you can actually measure the speed
> difference. For something like this, the compiler will always get it
> right without you having to do anything.
>
Thank you for your guidance.
I misuse it.
> And again, how can this fail? Have you seen it fail?
>
>> +pr_warn("%s:failed to allocate memory for the %u
>> vc_screenbuf\n",
>> +__func__, currcons);
>> +visual_deinit(vc);
>> +tty_port_destroy(>port);
>> +kfree(vc);
>> +vc_cons[currcons].d = NULL;
>> +break;
>> +}
>> vc_init(vc, vc->vc_rows, vc->vc_cols,
>> currcons || !vc->vc_sw->con_save_screen);
>> }
>> currcons = fg_console = 0;
>> master_display_fg = vc = vc_cons[currcons].d;
>> +if (unlikely(!vc)) {
>
> Again, never use likely/unlikely unless you can measure it.
>
> thanks,
>
> greg k-h
>
> .
>
thanks,
Xiaoming Ni
[PATCH v6 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[9b007000] pgd=00023d4f8003, pud=00023da9b003,
pmd=00023d4b3003, pte=36298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
in case there can be some obscure use-case.(by Kirill)
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Reported-by: Yibo Cai
Signed-off-by: Jia He
---
mm/memory.c | 65 -
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index e2bb51b6242e..7c38c1ce5440 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2140,8 +2147,12 @@ static inline int pte_unmap_same(struct mm_struct *mm,
pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned
long va, struct vm_area_struct *vma)
+static inline int cow_user_page(struct page *dst, struct page *src,
+ struct vm_fault *vmf)
{
+ struct vm_area_struct *vma = vmf->vma;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
/*
@@ -2151,21 +2162,52 @@ static inline void cow_user_page(struct page *dst,
struct page *src, unsigned lo
* fails, we just zero-fill it. Live with it.
*/
if (unlikely(!src)) {
- void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ void *kaddr;
+ void __user *uaddr = (void __user *)(addr & PAGE_MASK);
+ pte_t entry;
+
+ /* On architectures with software "accessed" bits, we would
+* take a double page fault, so mark it accessed here.
+*/
+ if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte)) {
+ spin_lock(vmf->ptl);
+ if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr,
+ vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ } else {
+ /* Other thread has already handled the fault
+* and we don't need to do anything. If it's
+* not the case, the fault will be triggered
+* again on the same address.
+*/
+ spin_unlock(vmf->ptl);
+ return -1;
+ }
+ spin_unlock(vmf->ptl);
+ }
+ kaddr = kmap_atomic(dst);
/*
* This really shouldn't fail, because the page is there
* in the page tables. But it might just be unreadable,
* in which case we just give up and fill the result with
* zeroes.
*/
- if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE))
+ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
+ /* Give a warn in case there can be some obscure
+* use-case
+*/
+ WARN_ON_ONCE(1);
clear_page(kaddr);
+ }
kunmap_atomic(kaddr);
flush_dcache_page(dst);
} else
-
[PATCH v6 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Reported-by: kbuild test robot
Suggested-by: Suzuki Poulose
Signed-off-by: Jia He
---
arch/arm64/include/asm/cpufeature.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index c96ffa4722d3..46caf934ba4e 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -667,6 +667,16 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int
parange)
default: return CONFIG_ARM64_PA_BITS;
}
}
+
+/* Decouple AF from AFDBM. */
+static inline bool cpu_has_hw_af(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
+ return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
+
+ return false;
+}
+
#endif /* __ASSEMBLY__ */
#endif
--
2.17.1
[PATCH v6 0/3] fix double page fault on arm64
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there will be a double page fault in __copy_from_user_inatomic of cow_user_page. As told by Catalin: "On arm64 without hardware Access Flag, copying from user will fail because the pte is old and cannot be marked young. So we always end up with zeroed page after fork() + CoW for pfn mappings. we don't always have a hardware-managed access flag on arm64." Changes v6: fix error case of returning with spinlock taken (Catalin) move kmap_atomic to avoid handling kunmap_atomic v5: handle the case correctly when !pte_same fix kbuild test failed v4: introduce cpu_has_hw_af (Suzuki) bail out if !pte_same (Kirill) v3: add vmf->ptl lock/unlock (Kirill A. Shutemov) add arch_faults_on_old_pte (Matthew, Catalin) v2: remove FAULT_FLAG_WRITE when setting pte access flag (Catalin) Jia He (3): arm64: cpufeature: introduce helper cpu_has_hw_af() arm64: mm: implement arch_faults_on_old_pte() on arm64 mm: fix double page fault on arm64 if PTE_AF is cleared arch/arm64/include/asm/cpufeature.h | 10 + arch/arm64/include/asm/pgtable.h| 12 ++ mm/memory.c | 65 ++--- 3 files changed, 81 insertions(+), 6 deletions(-) -- 2.17.1
[PATCH v6 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He
---
arch/arm64/include/asm/pgtable.h | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e09760ece844..4a9939615e41 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -868,6 +868,18 @@ static inline void update_mmu_cache(struct vm_area_struct
*vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying fromuser will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. we don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On Fri, Sep 20, 2019 at 09:30:58AM +0800, Jason Wang wrote:
> On 2019/9/19 下午11:45, Tiwei Bie wrote:
> > On Thu, Sep 19, 2019 at 09:08:11PM +0800, Jason Wang wrote:
> > > On 2019/9/18 下午10:32, Michael S. Tsirkin wrote:
> > > > > > > So I have some questions:
> > > > > > >
> > > > > > > 1) Compared to method 2, what's the advantage of creating a new
> > > > > > > vhost char
> > > > > > > device? I guess it's for keep the API compatibility?
> > > > > > One benefit is that we can avoid doing vhost ioctls on
> > > > > > VFIO device fd.
> > > > > Yes, but any benefit from doing this?
> > > > It does seem a bit more modular, but it's certainly not a big deal.
> > > Ok, if we go this way, it could be as simple as provide some callback to
> > > vhost, then vhost can just forward the ioctl through parent_ops.
> > >
> > > > > > > 2) For method 2, is there any easy way for user/admin to
> > > > > > > distinguish e.g
> > > > > > > ordinary vfio-mdev for vhost from ordinary vfio-mdev?
> > > > > > I think device-api could be a choice.
> > > > > Ok.
> > > > >
> > > > >
> > > > > > > I saw you introduce
> > > > > > > ops matching helper but it's not friendly to management.
> > > > > > The ops matching helper is just to check whether a given
> > > > > > vfio-device is based on a mdev device.
> > > > > >
> > > > > > > 3) A drawback of 1) and 2) is that it must follow vfio_device_ops
> > > > > > > that
> > > > > > > assumes the parameter comes from userspace, it prevents support
> > > > > > > kernel
> > > > > > > virtio drivers.
> > > > > > >
> > > > > > > 4) So comes the idea of method 3, since it register a new
> > > > > > > vhost-mdev driver,
> > > > > > > we can use device specific ops instead of VFIO ones, then we can
> > > > > > > have a
> > > > > > > common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
> > > > > > As the above draft shows, this requires introducing a new
> > > > > > VFIO device driver. I think Alex's opinion matters here.
> > > Just to clarify, a new type of mdev driver but provides dummy
> > > vfio_device_ops for VFIO to make container DMA ioctl work.
> > I see. Thanks! IIUC, you mean we can provide a very tiny
> > VFIO device driver in drivers/vhost/mdev.c, e.g.:
> >
> > static int vfio_vhost_mdev_open(void *device_data)
> > {
> > if (!try_module_get(THIS_MODULE))
> > return -ENODEV;
> > return 0;
> > }
> >
> > static void vfio_vhost_mdev_release(void *device_data)
> > {
> > module_put(THIS_MODULE);
> > }
> >
> > static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
> > .name = "vfio-vhost-mdev",
> > .open = vfio_vhost_mdev_open,
> > .release= vfio_vhost_mdev_release,
> > };
> >
> > static int vhost_mdev_probe(struct device *dev)
> > {
> > struct mdev_device *mdev = to_mdev_device(dev);
> >
> > ... Check the mdev device_id proposed in ...
> > ... https://lkml.org/lkml/2019/9/12/151 ...
>
>
> To clarify, this should be done through the id_table fields in
> vhost_mdev_driver, and it should claim it supports virtio-mdev device only:
>
>
> static struct mdev_class_id id_table[] = {
> { MDEV_ID_VIRTIO },
> { 0 },
> };
>
>
> static struct mdev_driver vhost_mdev_driver = {
> ...
> .id_table = id_table,
> }
In this way, both of virtio-mdev and vhost-mdev will try to
take this device. We may want a way to let vhost-mdev take this
device only when users explicitly ask it to do it. Or maybe we
can have a different MDEV_ID for vhost-mdev but share the device
ops with virtio-mdev.
>
>
> >
> > return vfio_add_group_dev(dev, _vhost_mdev_dev_ops, mdev);
>
>
> And in vfio_vhost_mdev_ops, all its need is to just implement vhost-net
> ioctl and translate them to virtio-mdev transport (e.g device_ops I proposed
> or ioctls other whatever other method) API.
I see, so my previous understanding is basically correct:
https://lkml.org/lkml/2019/9/17/332
I.e. we won't have a separate vhost fd and we will do all vhost
ioctls on the VFIO device fd backed by this new VFIO driver.
> And it could have a dummy ops
> implementation for the other device_ops.
>
>
> > }
> >
> > static void vhost_mdev_remove(struct device *dev)
> > {
> > vfio_del_group_dev(dev);
> > }
> >
> > static struct mdev_driver vhost_mdev_driver = {
> > .name = "vhost_mdev",
> > .probe = vhost_mdev_probe,
> > .remove = vhost_mdev_remove,
> > };
> >
> > So we can bind above mdev driver to the virtio-mdev compatible
> > mdev devices when we want to use vhost-mdev.
> >
> > After binding above driver to the mdev device, we can setup IOMMU
> > via VFIO and get VFIO device fd of this mdev device, and pass it
> > to vhost fd (/dev/vhost-mdev) with a SET_BACKEND ioctl.
>
>
> Then what vhost-mdev char device did is just forwarding ioctl back to this
> vfio device fd which seems a overkill. It's simpler that just do ioctl on
> the device ops directly.
Yes.
Thanks,
Tiwei
>
> Thanks
>
>
>
Re: [PATCH] x86/mm: fix return value of p[um]dp_set_access_flags
On Thu, Sep 19, 2019 at 10:25:05AM -0700, Dave Hansen wrote: >On 9/19/19 1:25 AM, Wei Yang wrote: >> Function p[um]dp_set_access_flags is used with update_mmu_cache_p[um]d >> and the return value from p[um]dp_set_access_flags indicates whether it >> is necessary to do the cache update. > >If this change is correct, why was it not applied to >ptep_set_access_flags()? That function has the same form. > Thanks, you are right, I missed this point. >BTW, I rather dislike the 'dirty' variable name. It seems to be >indicating whether the fault was a write fault or not and whether we >*expect* the dirty bit to be set in 'entry'. > I found some comments for ptep_set_access_flags in OLD code, which says /* * We only update the dirty/accessed state if we set * the dirty bit by hand in the kernel, since the hardware * will do the accessed bit for us, and we don't want to * race with other CPU's that might be updating the dirty * bit at the same time. */ I guess this is reason for the naming. Looks currently we use this value in some other way. >> From current code logic, only when changed && dirty, related page table >> entry would be updated. It is not necessary to update cache when the >> real page table entry is not changed. > >This logic doesn't really hold up, though. > >If we are only writing accessed and/or dirty bits, then we *never* need >to flush. The flush might avoid a stale TLB entry causing an extra page >walk by the hardware, but it's probably not ever worth the cost of the >flush. > >Unless there's something weird happening with paravirt, I can't ever see >a good reason to flush the TLB when just setting accessed/dirty bits on >bare-metal. > >This seems like a place where a debugging check to validate that only >accessed/dirty bits are only being set would be a good idea. The function update_mmu_cache_pmd is not for x86, IMHO, since it is empty on x86. I took a look into the definition on powerpc, which is defined in arch/powerpc/mm/book3s64/pgtable.c, which preload the content of this HPTE. So the cache update here is not TLB flush on x86. And then I compare the definition of ptep_set_access_flags on x86 and powerpc. On powerpc, which is defined in arch/powerpc/mm/pgtable.c, update the pte without checking *dirty*. This logic make sense to me. So I am confused with why on x86 we need to check both *changed* and *dirty*. Then I searched the history, and found commit 8dab5241d06bf may explain something. The commit log says: This patch reworks ptep_set_access_flags() semantics, implementations and callers so that it's now responsible for returning whether an update is necessary or not (basically whether the PTE actually changed). If my understanding is correct, the return value should indicate whether the PTE actually changed. But the change introduced in commit 8dab5241d06bf is not doing the exact thing on x86. Since we only change PTE only both *dirty* and *change*, just return *changed* seems not match the semantics. Last but not least, since update_mmu_cache_pmd is empty, even return value is not correct, it doesn't break anything. Hope my understanding is correct. -- Wei Yang Help you, Help me
[GIT PULL] Hexagon arch maintainer change
Hi Linus, Please pull the following changes. I am leaving QuIC, and Brian Cain will be taking over maintainership of the Hexagon port. Thanks, Richard Kuo The following changes since commit 4d856f72c10ecb060868ed10ff1b1453943fc6c8: Linux 5.3 (2019-09-15 14:19:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rkuo/linux-hexagon-kernel.git for-linus for you to fetch changes up to 18dd1793a340f8216e22c9295c0c7b95cdae1783: Hexagon: change maintainer to Brian Cain (2019-09-19 14:58:15 -0500) Brian Cain (1): Hexagon: change maintainer to Brian Cain MAINTAINERS | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project
Re: [PATCH v2 1/1] powerpc/pseries/hotplug-memory.c: Change rc variable to bool
Hello Michael,
Any feedback on this patch?
Best regards,
On Fri, 2019-08-02 at 15:45 +0200, David Hildenbrand wrote:
> On 02.08.19 15:39, Leonardo Bras wrote:
> > Changes the return variable to bool (as the return value) and
> > avoids doing a ternary operation before returning.
> >
> > Signed-off-by: Leonardo Bras
> > ---
> > Changes in v2:
> > - Restore previous and-ing logic on rc.
> >
> > arch/powerpc/platforms/pseries/hotplug-memory.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c
> > b/arch/powerpc/platforms/pseries/hotplug-memory.c
> > index 8e700390f3d6..c126b94d1943 100644
> > --- a/arch/powerpc/platforms/pseries/hotplug-memory.c
> > +++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
> > @@ -338,7 +338,7 @@ static int pseries_remove_mem_node(struct device_node
> > *np)
> > static bool lmb_is_removable(struct drmem_lmb *lmb)
> > {
> > int i, scns_per_block;
> > - int rc = 1;
> > + bool rc = true;
> > unsigned long pfn, block_sz;
> > u64 phys_addr;
> >
> > @@ -363,11 +363,11 @@ static bool lmb_is_removable(struct drmem_lmb *lmb)
> > if (!pfn_present(pfn))
> > continue;
> >
> > - rc &= is_mem_section_removable(pfn, PAGES_PER_SECTION);
> > + rc = rc && is_mem_section_removable(pfn, PAGES_PER_SECTION);
> > phys_addr += MIN_MEMORY_BLOCK_SIZE;
> > }
> >
> > - return rc ? true : false;
> > + return rc;
> > }
> >
> > static int dlpar_add_lmb(struct drmem_lmb *);
> >
>
> Yeah, why not
>
> Reviewed-by: David Hildenbrand
>
signature.asc
Description: This is a digitally signed message part
[PATCH -next] PCI: tegra: Add missing include file
Fix build error without CONFIG_PINCTRL
drivers/pci/controller/dwc/pcie-tegra194.c: In function tegra_pcie_config_rp:
drivers/pci/controller/dwc/pcie-tegra194.c:1394:8: error: implicit declaration
of function pinctrl_pm_select_default_state;
did you mean prandom_seed_full_state? [-Werror=implicit-function-declaration]
ret = pinctrl_pm_select_default_state(dev);
^~~
prandom_seed_full_state
Reported-by: Hulk Robot
Fixes: ab2a50e7602b ("PCI: tegra: Add support to configure sideband pins")
Signed-off-by: YueHaibing
---
drivers/pci/controller/dwc/pcie-tegra194.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c
b/drivers/pci/controller/dwc/pcie-tegra194.c
index 09ed8e4..b219d3b2 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include "pcie-designware.h"
#include
#include
--
2.7.4
[PATCH] staging: rtl8192u: release memory on error path
In rtl819xU_tx_cmd if usb_submit_urb fails the allocated memories should
be released.
Signed-off-by: Navid Emamdoost
---
drivers/staging/rtl8192u/r8192U_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/rtl8192u/r8192U_core.c
b/drivers/staging/rtl8192u/r8192U_core.c
index fe1f279ca368..401561705d9d 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1232,6 +1232,8 @@ short rtl819xU_tx_cmd(struct net_device *dev, struct
sk_buff *skb)
return 0;
DMESGE("Error TX CMD URB, error %d", status);
+ dev_kfree_skb(skb);
+ usb_free_urb(tx_urb);
return -1;
}
--
2.17.1
Re: [RFC {net,iproute2}-next 0/2] Introduce an eBPF hookpoint for tx queue selection in the XPS (Transmit Packet Steering) code.
On 2019/9/20 上午8:05, Matt Cover wrote:
On Thu, Sep 19, 2019 at 3:45 PM Matthew Cover wrote:
WORK IN PROGRESS:
* bpf program loading works!
* txq steering via bpf program return code works!
* bpf program unloading not working.
* bpf program attached query not working.
This patch set provides a bpf hookpoint with goals similar to, but a more
generic implementation than, TUNSETSTEERINGEBPF; userspace supplied tx queue
selection policy.
One point that I introduce TUNSETSTEERINGEBPF instead of using a generic
way like cls/act bpf is that I need make sure to have a consistent API
with macvtap.
In the case of macvtap, TX means transmit from userspace to kernel, but
for TUN, it means transmit from kernel to userspace.
TUNSETSTEERINGEBPF is a useful bpf hookpoint, but has some drawbacks.
First, it only works on tun/tap devices.
Second, there is no way in the current TUNSETSTEERINGEBPF implementation
to bail out or load a noop bpf prog and fallback to the no prog tx queue
selection method.
I believe it expect that eBPF should take all the parts (even the
fallback part).
Third, the TUNSETSTEERINGEBPF interface seems to require possession of existing
or creation of new queues/fds.
That's the way TUN work for past +10 years because ioctl is the only way
to do configuration and it requires a fd to carry that. David suggest to
implement netlink but nobody did that.
This most naturally fits in the "wire" implementation since possession of fds
is ensured. However, it also means the various "wire" implementations (e.g.
qemu) have to all be made aware of TUNSETSTEERINGEBPF and expose an interface
to load/unload a bpf prog (or provide a mechanism to pass an fd to another
program).
The load/unload of ebpf program is standard bpf() syscall. Ioctl just
attach that to TUN. This idea is borrowed from packet socket which the
bpf program was attached through setsockopt().
Alternatively, you can spin up an extra queue and immediately disable via
IFF_DETACH_QUEUE, but this seems unsafe; packets could be enqueued to this
extra file descriptor which is part of our bpf prog loader, not our "wire".
You can use you 'wire' queue to do ioctl, but we can invent other API.
Placing this in the XPS code and leveraging iproute2 and rtnetlink to provide
our bpf prog loader in a similar manner to xdp gives us a nice way to separate
the tap "wire" and the loading of tx queue selection policy. It also lets us
use this hookpoint for any device traversing XPS.
This patch only introduces the new hookpoint to the XPS code and will not yet
be used by tun/tap devices using the intree tun.ko (which implements an
.ndo_select_queue and does not traverse the XPS code).
In a future patch set, we can optionally refactor tun.ko to traverse this call
to bpf_prog_run_clear_cb() and bpf prog storage. tun/tap devices could then
leverage iproute2 as a generic loader. The TUNSETSTEERINGEBPF interface could
at this point be optionally deprecated/removed.
As described above, we need it for macvtap and you propose here can not
work for that.
I'm not against this proposal, just want to clarify some considerations
when developing TUNSETSTEERINGEPF. The main goal is for VM to implement
sophisticated steering policy like RSS without touching kernel.
Thanks
Both patches in this set have been tested using a rebuilt tun.ko with no
.ndo_select_queue.
sed -i '/\.ndo_select_queue.*=/d' drivers/net/tun.c
The tap device was instantiated using tap_mq_pong.c, supporting scripts, and
wrapping service found here:
https://github.com/stackpath/rxtxcpu/tree/v1.2.6/helpers
The bpf prog source and test scripts can be found here:
https://github.com/werekraken/xps_ebpf
In nstxq, netsniff-ng using PACKET_FANOUT_QM is leveraged to check the
queue_mapping.
With no prog loaded, the tx queue selection is adhering our xps_cpus
configuration.
[vagrant@localhost ~]$ grep . /sys/class/net/tap0/queues/tx-*/xps_cpus;
./nstxq; sudo timeout 1 cat /sys/kernel/debug/tracing/trace_pipe;
/sys/class/net/tap0/queues/tx-0/xps_cpus:1
/sys/class/net/tap0/queues/tx-1/xps_cpus:2
cpu0: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.146 ms
cpu0: qm0: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
Len 84 Type 8 Code 0
cpu1: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.121 ms
cpu1: qm1: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
Len 84 Type 8 Code 0
With a return 0 bpg prog, our tx queue is 0 (despite xps_cpus).
[vagrant@localhost ~]$ sudo ip link set dev tap0 xps obj hello0.o sec hello
&& { ./nstxq; sudo timeout 1 cat /sys/kernel/debug/tracing/trace_pipe; }
cpu0: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.160 ms
cpu0: qm0: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
Len 84 Type 8 Code 0
cpu1: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.124 ms
cpu1: qm0: > tap0
Re: [PATCH] net/ncsi: Disable global multicast filter
On Thu, 12 Sep 2019 12:04:50 -0700, Vijay Khemka wrote:
> Disabling multicast filtering from NCSI if it is supported. As it
> should not filter any multicast packets. In current code, multicast
> filter is enabled and with an exception of optional field supported
> by device are disabled filtering.
>
> Mainly I see if goal is to disable filtering for IPV6 packets then let
> it disabled for every other types as well. As we are seeing issues with
> LLDP not working with this enabled filtering. And there are other issues
> with IPV6.
>
> By Disabling this multicast completely, it is working for both IPV6 as
> well as LLDP.
>
> Signed-off-by: Vijay Khemka
> @@ -1033,23 +1030,23 @@ static void ncsi_configure_channel(struct
> ncsi_dev_priv *ndp)
> } else if (nd->state == ncsi_dev_state_config_ebf) {
> nca.type = NCSI_PKT_CMD_EBF;
> nca.dwords[0] = nc->caps[NCSI_CAP_BC].cap;
> - if (ncsi_channel_is_tx(ndp, nc))
> + /* if multicast global filtering is supported then
> + * disable it so that all multicast packet will be
> + * forwarded to management controller
> + */
> + if (nc->caps[NCSI_CAP_GENERIC].cap &
> + NCSI_CAP_GENERIC_MC)
Applied, looks like an unnecessary space sneaked in here, I removed it.
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/19 下午11:45, Tiwei Bie wrote:
On Thu, Sep 19, 2019 at 09:08:11PM +0800, Jason Wang wrote:
On 2019/9/18 下午10:32, Michael S. Tsirkin wrote:
So I have some questions:
1) Compared to method 2, what's the advantage of creating a new vhost char
device? I guess it's for keep the API compatibility?
One benefit is that we can avoid doing vhost ioctls on
VFIO device fd.
Yes, but any benefit from doing this?
It does seem a bit more modular, but it's certainly not a big deal.
Ok, if we go this way, it could be as simple as provide some callback to
vhost, then vhost can just forward the ioctl through parent_ops.
2) For method 2, is there any easy way for user/admin to distinguish e.g
ordinary vfio-mdev for vhost from ordinary vfio-mdev?
I think device-api could be a choice.
Ok.
I saw you introduce
ops matching helper but it's not friendly to management.
The ops matching helper is just to check whether a given
vfio-device is based on a mdev device.
3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
assumes the parameter comes from userspace, it prevents support kernel
virtio drivers.
4) So comes the idea of method 3, since it register a new vhost-mdev driver,
we can use device specific ops instead of VFIO ones, then we can have a
common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
As the above draft shows, this requires introducing a new
VFIO device driver. I think Alex's opinion matters here.
Just to clarify, a new type of mdev driver but provides dummy
vfio_device_ops for VFIO to make container DMA ioctl work.
I see. Thanks! IIUC, you mean we can provide a very tiny
VFIO device driver in drivers/vhost/mdev.c, e.g.:
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
module_put(THIS_MODULE);
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release= vfio_vhost_mdev_release,
};
static int vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
... Check the mdev device_id proposed in ...
... https://lkml.org/lkml/2019/9/12/151 ...
To clarify, this should be done through the id_table fields in
vhost_mdev_driver, and it should claim it supports virtio-mdev device only:
static struct mdev_class_id id_table[] = {
{ MDEV_ID_VIRTIO },
{ 0 },
};
static struct mdev_driver vhost_mdev_driver = {
...
.id_table = id_table,
}
return vfio_add_group_dev(dev, _vhost_mdev_dev_ops, mdev);
And in vfio_vhost_mdev_ops, all its need is to just implement vhost-net
ioctl and translate them to virtio-mdev transport (e.g device_ops I
proposed or ioctls other whatever other method) API. And it could have a
dummy ops implementation for the other device_ops.
}
static void vhost_mdev_remove(struct device *dev)
{
vfio_del_group_dev(dev);
}
static struct mdev_driver vhost_mdev_driver = {
.name = "vhost_mdev",
.probe = vhost_mdev_probe,
.remove = vhost_mdev_remove,
};
So we can bind above mdev driver to the virtio-mdev compatible
mdev devices when we want to use vhost-mdev.
After binding above driver to the mdev device, we can setup IOMMU
via VFIO and get VFIO device fd of this mdev device, and pass it
to vhost fd (/dev/vhost-mdev) with a SET_BACKEND ioctl.
Then what vhost-mdev char device did is just forwarding ioctl back to
this vfio device fd which seems a overkill. It's simpler that just do
ioctl on the device ops directly.
Thanks
Thanks,
Tiwei
Thanks
Yes, it is.
Thanks
RE: [PATCH V2 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure to common place
Gentle ping...
> Subject: [PATCH V2 1/2] clk: imx8mm: Move 1443X/1416X PLL clock structure
> to common place
>
> Many i.MX8M SoCs use same 1443X/1416X PLL, such as i.MX8MM, i.MX8MN
> and later i.MX8M SoCs, moving these PLL definitions to pll14xx driver can
> save a lot of duplicated code on each platform.
>
> Meanwhile, no need to define PLL clock structure for every module which
> uses same type of PLL, e.g., audio/video/dram use 1443X PLL,
> arm/gpu/vpu/sys use 1416X PLL, define 2 PLL clock structure for each group
> is enough.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V1:
> - Move 1443X/1416X PLL clock table/structure to pll14xx driver.
> ---
> drivers/clk/imx/clk-imx8mm.c | 87
> +--
> drivers/clk/imx/clk-pll14xx.c | 30 +++
> drivers/clk/imx/clk.h | 3 ++
> 3 files changed, 43 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index 2758e3f..9649250 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -26,73 +26,6 @@ static u32 share_count_disp; static u32
> share_count_pdm; static u32 share_count_nand;
>
> -static const struct imx_pll14xx_rate_table imx8mm_pll1416x_tbl[] = {
> - PLL_1416X_RATE(18U, 225, 3, 0),
> - PLL_1416X_RATE(16U, 200, 3, 0),
> - PLL_1416X_RATE(12U, 300, 3, 1),
> - PLL_1416X_RATE(10U, 250, 3, 1),
> - PLL_1416X_RATE(8U, 200, 3, 1),
> - PLL_1416X_RATE(75000U, 250, 2, 2),
> - PLL_1416X_RATE(7U, 350, 3, 2),
> - PLL_1416X_RATE(6U, 300, 3, 2),
> -};
> -
> -static const struct imx_pll14xx_rate_table imx8mm_audiopll_tbl[] = {
> - PLL_1443X_RATE(393216000U, 262, 2, 3, 9437),
> - PLL_1443X_RATE(361267200U, 361, 3, 3, 17511),
> -};
> -
> -static const struct imx_pll14xx_rate_table imx8mm_videopll_tbl[] = {
> - PLL_1443X_RATE(65000U, 325, 3, 2, 0),
> - PLL_1443X_RATE(59400U, 198, 2, 2, 0),
> -};
> -
> -static const struct imx_pll14xx_rate_table imx8mm_drampll_tbl[] = {
> - PLL_1443X_RATE(65000U, 325, 3, 2, 0),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_audio_pll = {
> - .type = PLL_1443X,
> - .rate_table = imx8mm_audiopll_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_audiopll_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_video_pll = {
> - .type = PLL_1443X,
> - .rate_table = imx8mm_videopll_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_videopll_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_dram_pll = {
> - .type = PLL_1443X,
> - .rate_table = imx8mm_drampll_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_drampll_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_arm_pll = {
> - .type = PLL_1416X,
> - .rate_table = imx8mm_pll1416x_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_gpu_pll = {
> - .type = PLL_1416X,
> - .rate_table = imx8mm_pll1416x_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_vpu_pll = {
> - .type = PLL_1416X,
> - .rate_table = imx8mm_pll1416x_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
> -};
> -
> -static struct imx_pll14xx_clk imx8mm_sys_pll = {
> - .type = PLL_1416X,
> - .rate_table = imx8mm_pll1416x_tbl,
> - .rate_count = ARRAY_SIZE(imx8mm_pll1416x_tbl),
> -};
> -
> static const char *pll_ref_sels[] = { "osc_24m", "dummy", "dummy",
> "dummy", }; static const char *audio_pll1_bypass_sels[] = {"audio_pll1",
> "audio_pll1_ref_sel", }; static const char *audio_pll2_bypass_sels[] =
> {"audio_pll2", "audio_pll2_ref_sel", }; @@ -396,16 +329,16 @@ static int
> imx8mm_clocks_probe(struct platform_device *pdev)
> clks[IMX8MM_SYS_PLL2_REF_SEL] = imx_clk_mux("sys_pll2_ref_sel",
> base + 0x104, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
> clks[IMX8MM_SYS_PLL3_REF_SEL] = imx_clk_mux("sys_pll3_ref_sel",
> base + 0x114, 0, 2, pll_ref_sels, ARRAY_SIZE(pll_ref_sels));
>
> - clks[IMX8MM_AUDIO_PLL1] = imx_clk_pll14xx("audio_pll1",
> "audio_pll1_ref_sel", base, _audio_pll);
> - clks[IMX8MM_AUDIO_PLL2] = imx_clk_pll14xx("audio_pll2",
> "audio_pll2_ref_sel", base + 0x14, _audio_pll);
> - clks[IMX8MM_VIDEO_PLL1] = imx_clk_pll14xx("video_pll1",
> "video_pll1_ref_sel", base + 0x28, _video_pll);
> - clks[IMX8MM_DRAM_PLL] = imx_clk_pll14xx("dram_pll",
> "dram_pll_ref_sel", base + 0x50, _dram_pll);
> - clks[IMX8MM_GPU_PLL] = imx_clk_pll14xx("gpu_pll",
> "gpu_pll_ref_sel", base + 0x64, _gpu_pll);
> - clks[IMX8MM_VPU_PLL] = imx_clk_pll14xx("vpu_pll",
> "vpu_pll_ref_sel", base + 0x74, _vpu_pll);
> - clks[IMX8MM_ARM_PLL] = imx_clk_pll14xx("arm_pll",
>
[GIT PULL] tracing: Updates for 5.4
Linus, Tracing updates: - Addition of multiprobes to kprobe and uprobe events Allows for more than one probe attached to the same location - Addition of adding immediates to probe parameters - Clean up of the recordmcount.c code. This brings us closer to merging recordmcount into objtool, and reuse code. - Other small clean ups Please pull the latest trace-v5.4 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-v5.4 Tag SHA1: c7ec8cea00f554d7f234b4e8f4fdc0b0a89b564f Head SHA1: b78b94b82122208902c0f83805e614e1239f9893 Andy Shevchenko (1): tracing: Be more clever when dumping hex in __print_hex() Changbin Du (1): ftrace: Simplify ftrace hash lookup code in clear_func_from_hash() Masami Hiramatsu (17): kprobes: Allow kprobes coexist with livepatch tracing/probe: Split trace_event related data from trace_probe tracing/dynevent: Delete all matched events tracing/dynevent: Pass extra arguments to match operation tracing/kprobe: Add multi-probe per event support tracing/uprobe: Add multi-probe per uprobe event support tracing/kprobe: Add per-probe delete from event tracing/uprobe: Add per-probe delete from event tracing/probe: Add immediate parameter support tracing/probe: Add immediate string parameter support selftests/ftrace: Add a testcase for kprobe multiprobe event selftests/ftrace: Add syntax error test for immediates selftests/ftrace: Add syntax error test for multiprobe tracing/kprobe: Fix NULL pointer access in trace_porbe_unlink() tracing/probe: Fix to allow user to enable events on unloaded modules tracing/probe: Reject exactly same probe event selftests/ftrace: Update kprobe event error testcase Matt Helsley (8): recordmcount: Remove redundant strcmp recordmcount: Remove uread() recordmcount: Remove unused fd from uwrite() and ulseek() recordmcount: Rewrite error/success handling recordmcount: Kernel style function signature formatting recordmcount: Kernel style formatting recordmcount: Remove redundant cleanup() calls recordmcount: Clarify what cleanup() does Steven Rostedt (VMware) (4): tracing/arm64: Have max stack tracer handle the case of return address after data tracing: Document the stack trace algorithm in the comments tracing: Rename tracing_reset() to tracing_reset_cpu() selftests/ftrace: Select an existing function in kprobe_eventname test Tom Zanussi (1): tracing: Make sure variable reference alias has correct var_ref_idx Zhengjun Xing (1): tracing: Add "gfp_t" support in synthetic_events Documentation/trace/kprobetrace.rst| 1 + Documentation/trace/uprobetracer.rst | 1 + arch/arm64/include/asm/ftrace.h| 13 + kernel/kprobes.c | 56 +++- kernel/trace/ftrace.c | 6 +- kernel/trace/trace.c | 14 +- kernel/trace/trace.h | 1 - kernel/trace/trace_dynevent.c | 10 +- kernel/trace/trace_dynevent.h | 7 +- kernel/trace/trace_events_hist.c | 25 +- kernel/trace/trace_kprobe.c| 268 + kernel/trace/trace_output.c| 6 +- kernel/trace/trace_probe.c | 178 ++-- kernel/trace/trace_probe.h | 68 - kernel/trace/trace_stack.c | 112 +++ kernel/trace/trace_uprobe.c| 299 +++ scripts/recordmcount.c | 321 ++--- scripts/recordmcount.h | 150 +++--- tools/testing/selftests/ftrace/test.d/functions| 2 +- .../ftrace/test.d/kprobe/kprobe_eventname.tc | 16 +- .../ftrace/test.d/kprobe/kprobe_multiprobe.tc | 35 +++ .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 16 + 22 files changed, 1199 insertions(+), 406 deletions(-) create mode 100644 tools/testing/selftests/ftrace/test.d/kprobe/kprobe_multiprobe.tc ---
Re: [PATCH] devfreq: Make log message more explicit when devfreq device already exists
Hi,
On 19. 9. 19. 오전 9:09, Matthias Kaehlcke wrote:
> Before creating a new devfreq device devfreq_add_device() checks
> if there is already a devfreq dev associated with the requesting
> device (parent). If that's the case the function rejects to create
> another devfreq dev for that parent and logs an error. The error
> message is very unspecific, make it a bit more explicit.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> drivers/devfreq/devfreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index ab22bf8a12d6..0e2dd734ab58 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -625,7 +625,7 @@ struct devfreq *devfreq_add_device(struct device *dev,
> devfreq = find_device_devfreq(dev);
> mutex_unlock(_list_lock);
> if (!IS_ERR(devfreq)) {
> - dev_err(dev, "%s: Unable to create devfreq for the device.\n",
> + dev_err(dev, "%s: devfreq device already exists!\n",
Looks good to me. But After edited the log message, you can make
it on one line because the length is not over 80 char.
You can change it for the readability as following:
if (!IS_ERR(devfreq)) {
- dev_err(dev, "%s: Unable to create devfreq for the device.\n",
- __func__);
+ dev_err(dev, "%s: devfreq device already exists.\n", __func__);
If you agree my comment, you can feel free to add my tag:
Reviewed-by: Chanwoo Choi
> __func__);
> err = -EINVAL;
> goto err_out;
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
Re: [PATCH 1/2] soc: ti: big cleanup of Kconfig file
On 9/19/19 3:33 PM, Randy Dunlap wrote:
From: Randy Dunlap
Cleanup drivers/soc/ti/Kconfig:
- delete duplicate words
- end sentences with '.'
- fix typos/spellos
- Subsystem is one word
- capitalize acronyms
- reflow lines to be <= 80 columns
Fixes: 41f93af900a2 ("soc: ti: add Keystone Navigator QMSS driver")
Fixes: 88139ed03058 ("soc: ti: add Keystone Navigator DMA support")
Fixes: afe761f8d3e9 ("soc: ti: Add pm33xx driver for basic suspend support")
Fixes: 5a99ae0092fe ("soc: ti: pm33xx: AM437X: Add rtc_only with ddr in self-refresh
support")
Fixes: a869b7b30dac ("soc: ti: Add Support for AM654 SoC config option")
Fixes: cff377f7897a ("soc: ti: Add Support for J721E SoC config option")
Signed-off-by: Randy Dunlap
Cc: Olof Johansson
Cc: Santosh Shilimkar
Cc: Sandeep Nair
Cc: Dave Gerlach
Cc: Keerthy
Cc: Tony Lindgren
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
---
@Santosh: MAINTAINERS says that you maintain drivers/soc/ti/*,
but there is more that Keystone-related code in that subdirectory
now... just in case you want to update that info.
Yes am aware there more drivers and so far I have been taking
care of everything in drivers/soc/ti/*
drivers/soc/ti/Kconfig | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
Patch looks fine to me. Do you want me to pick this up ?
RE: [PATCH v5 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
Hi Catalin
> -Original Message-
> From: Catalin Marinas
> Sent: 2019年9月20日 0:42
> To: Justin He (Arm Technology China)
> Cc: Will Deacon ; Mark Rutland
> ; James Morse ; Marc
> Zyngier ; Matthew Wilcox ; Kirill A.
> Shutemov ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Suzuki Poulose ; Punit
> Agrawal ; Anshuman Khandual
> ; Alex Van Brunt
> ; Robin Murphy ;
> Thomas Gleixner ; Andrew Morton foundation.org>; Jérôme Glisse ; Ralph Campbell
> ; hejia...@gmail.com; Kaly Xin (Arm Technology
> China)
> Subject: Re: [PATCH v5 3/3] mm: fix double page fault on arm64 if PTE_AF
> is cleared
>
> On Fri, Sep 20, 2019 at 12:12:04AM +0800, Jia He wrote:
> > @@ -2152,7 +2163,29 @@ static inline void cow_user_page(struct page
> *dst, struct page *src, unsigned lo
> > */
> > if (unlikely(!src)) {
> > void *kaddr = kmap_atomic(dst);
> > - void __user *uaddr = (void __user *)(va & PAGE_MASK);
> > + void __user *uaddr = (void __user *)(addr & PAGE_MASK);
> > + pte_t entry;
> > +
> > + /* On architectures with software "accessed" bits, we would
> > +* take a double page fault, so mark it accessed here.
> > +*/
> > + if (arch_faults_on_old_pte() && !pte_young(vmf->orig_pte))
> {
> > + spin_lock(vmf->ptl);
> > + if (likely(pte_same(*vmf->pte, vmf->orig_pte))) {
> > + entry = pte_mkyoung(vmf->orig_pte);
> > + if (ptep_set_access_flags(vma, addr,
> > + vmf->pte, entry, 0))
> > + update_mmu_cache(vma, addr, vmf-
> >pte);
> > + } else {
> > + /* Other thread has already handled the
> fault
> > +* and we don't need to do anything. If it's
> > +* not the case, the fault will be triggered
> > +* again on the same address.
> > +*/
> > + return -1;
> > + }
> > + spin_unlock(vmf->ptl);
>
> Returning with the spinlock held doesn't normally go very well ;).
Yes, my bad. Will fix asap
--
Cheers,
Justin (Jia He)
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
RE: [PATCH v5 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
Hi Catalin
> -Original Message-
> From: Catalin Marinas
> Sent: 2019年9月20日 0:37
> To: Justin He (Arm Technology China)
> Cc: Will Deacon ; Mark Rutland
> ; James Morse ; Marc
> Zyngier ; Matthew Wilcox ; Kirill A.
> Shutemov ; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; linux-
> m...@kvack.org; Suzuki Poulose ; Punit
> Agrawal ; Anshuman Khandual
> ; Alex Van Brunt
> ; Robin Murphy ;
> Thomas Gleixner ; Andrew Morton foundation.org>; Jérôme Glisse ; Ralph Campbell
> ; hejia...@gmail.com; Kaly Xin (Arm Technology
> China)
> Subject: Re: [PATCH v5 1/3] arm64: cpufeature: introduce helper
> cpu_has_hw_af()
>
> On Fri, Sep 20, 2019 at 12:12:02AM +0800, Jia He wrote:
> > diff --git a/arch/arm64/kernel/cpufeature.c
> b/arch/arm64/kernel/cpufeature.c
> > index b1fdc486aed8..fb0e9425d286 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -1141,6 +1141,16 @@ static bool has_hw_dbm(const struct
> arm64_cpu_capabilities *cap,
> > return true;
> > }
> >
> > +/* Decouple AF from AFDBM. */
> > +bool cpu_has_hw_af(void)
> > +{
> > + return (read_cpuid(ID_AA64MMFR1_EL1) & 0xf);
> > +}
> > +#else /* CONFIG_ARM64_HW_AFDBM */
> > +bool cpu_has_hw_af(void)
> > +{
> > + return false;
> > +}
> > #endif
>
> Please place this function in cpufeature.h directly, no need for an
> additional function call. Something like:
>
> static inline bool cpu_has_hw_af(void)
> {
> if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
> return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
> return false;
> }
>
Ok, thanks
--
Cheers,
Justin (Jia He)
> --
> Catalin
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
Re: [PATCH v2] devfreq: Add tracepoint for frequency changes
Hi,
On 19. 9. 20. 오전 2:44, Matthias Kaehlcke wrote:
> Add a tracepoint for frequency changes of devfreq devices and
> use it.
>
> Signed-off-by: Matthias Kaehlcke
> ---
> (sending v2 without much delay wrt v1, since the change in devfreq
> probably isn't controversial, and I'll be offline a few days)
>
> Changes in v2:
> - included trace_devfreq_frequency_enabled() in the condition
> to avoid unnecessary evaluation when the trace point is
> disabled
> ---
> drivers/devfreq/devfreq.c | 3 +++
> include/trace/events/devfreq.h | 18 ++
> 2 files changed, 21 insertions(+)
>
> diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
> index ab22bf8a12d6..e9f04dcafb01 100644
> --- a/drivers/devfreq/devfreq.c
> +++ b/drivers/devfreq/devfreq.c
> @@ -317,6 +317,9 @@ static int devfreq_set_target(struct devfreq *devfreq,
> unsigned long new_freq,
>
> devfreq->previous_freq = new_freq;
>
> + if (trace_devfreq_frequency_enabled() && new_freq != cur_freq)
> + trace_devfreq_frequency(devfreq, new_freq);
You can change as following without 'new_freq' variable
because devfreq->previous_freq is the new frequency.
trace_devfreq_frequency(devfreq);
> +
> if (devfreq->suspend_freq)
> devfreq->resume_freq = cur_freq;
>
> diff --git a/include/trace/events/devfreq.h b/include/trace/events/devfreq.h
> index cf5b8772175d..a62d32fe3c33 100644
> --- a/include/trace/events/devfreq.h
> +++ b/include/trace/events/devfreq.h
> @@ -8,6 +8,24 @@
> #include
> #include
>
> +TRACE_EVENT(devfreq_frequency,
> + TP_PROTO(struct devfreq *devfreq, unsigned long freq),
'unsigned long freq' parameter is not necessary.
> +
> + TP_ARGS(devfreq, freq),
> +
> + TP_STRUCT__entry(
> + __string(dev_name, dev_name(>dev))
> + __field(unsigned long, freq)
> + ),
> +
> + TP_fast_assign(
> + __assign_str(dev_name, dev_name(>dev));
> + __entry->freq = freq;
Initialize the new frequency with 'devfreq->previous_freq' as following:
__entry->freq = devfreq->previous_freq;
> + ),
> +
> + TP_printk("dev_name=%s freq=%lu", __get_str(dev_name), __entry->freq)
> +);
> +
> TRACE_EVENT(devfreq_monitor,
> TP_PROTO(struct devfreq *devfreq),
>
>
--
Best Regards,
Chanwoo Choi
Samsung Electronics
drivers/crypto/inside-secure/safexcel.c:840:9: error: implicit declaration of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'?
Hi Pascal,
FYI, the error/warning still remains.
tree:
https://kernel.googlesource.com/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 574cc4539762561d96b456dbc0544d8898bd4c6e
commit: 625f269a5a7a3643771320387e474bd0a61d9654 crypto: inside-secure - add
support for PCI based FPGA development board
date: 3 weeks ago
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 625f269a5a7a3643771320387e474bd0a61d9654
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=sh
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/crypto/inside-secure/safexcel.c: In function
'safexcel_request_ring_irq':
>> drivers/crypto/inside-secure/safexcel.c:840:9: error: implicit declaration
>> of function 'pci_irq_vector'; did you mean 'rcu_irq_enter'?
>> [-Werror=implicit-function-declaration]
irq = pci_irq_vector(pci_pdev, irqid);
^~
rcu_irq_enter
drivers/crypto/inside-secure/safexcel.c: In function
'safexcel_probe_generic':
>> drivers/crypto/inside-secure/safexcel.c:1043:9: error: implicit declaration
>> of function 'pci_alloc_irq_vectors'; did you mean 'pci_alloc_consistent'?
>> [-Werror=implicit-function-declaration]
ret = pci_alloc_irq_vectors(pci_pdev,
^
pci_alloc_consistent
>> drivers/crypto/inside-secure/safexcel.c:1046:10: error: 'PCI_IRQ_MSI'
>> undeclared (first use in this function); did you mean 'IRQ_MSK'?
PCI_IRQ_MSI | PCI_IRQ_MSIX);
^~~
IRQ_MSK
drivers/crypto/inside-secure/safexcel.c:1046:10: note: each undeclared
identifier is reported only once for each function it appears in
>> drivers/crypto/inside-secure/safexcel.c:1046:24: error: 'PCI_IRQ_MSIX'
>> undeclared (first use in this function); did you mean 'PCI_IRQ_MSI'?
PCI_IRQ_MSI | PCI_IRQ_MSIX);
^~~~
PCI_IRQ_MSI
drivers/crypto/inside-secure/safexcel.c: In function 'safexcel_init':
drivers/crypto/inside-secure/safexcel.c:1402:6: warning: unused variable
'rc' [-Wunused-variable]
int rc;
^~
cc1: some warnings being treated as errors
vim +840 drivers/crypto/inside-secure/safexcel.c
826
827 static int safexcel_request_ring_irq(void *pdev, int irqid,
828 int is_pci_dev,
829 irq_handler_t handler,
830 irq_handler_t threaded_handler,
831 struct safexcel_ring_irq_data
*ring_irq_priv)
832 {
833 int ret, irq;
834 struct device *dev;
835
836 if (IS_ENABLED(CONFIG_PCI) && is_pci_dev) {
837 struct pci_dev *pci_pdev = pdev;
838
839 dev = _pdev->dev;
> 840 irq = pci_irq_vector(pci_pdev, irqid);
841 if (irq < 0) {
842 dev_err(dev, "unable to get device MSI IRQ %d
(err %d)\n",
843 irqid, irq);
844 return irq;
845 }
846 } else if (IS_ENABLED(CONFIG_OF)) {
847 struct platform_device *plf_pdev = pdev;
848 char irq_name[6] = {0}; /* "ringX\0" */
849
850 snprintf(irq_name, 6, "ring%d", irqid);
851 dev = _pdev->dev;
852 irq = platform_get_irq_byname(plf_pdev, irq_name);
853
854 if (irq < 0) {
855 dev_err(dev, "unable to get IRQ '%s' (err
%d)\n",
856 irq_name, irq);
857 return irq;
858 }
859 }
860
861 ret = devm_request_threaded_irq(dev, irq, handler,
862 threaded_handler, IRQF_ONESHOT,
863 dev_name(dev), ring_irq_priv);
864 if (ret) {
865 dev_err(dev, "unable to request IRQ %d\n", irq);
866 return ret;
867 }
868
869 return irq;
870 }
871
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
Re: [RFC v4 0/3] vhost: introduce mdev based hardware backend
On 2019/9/19 下午11:45, Tiwei Bie wrote:
On Thu, Sep 19, 2019 at 09:08:11PM +0800, Jason Wang wrote:
On 2019/9/18 下午10:32, Michael S. Tsirkin wrote:
So I have some questions:
1) Compared to method 2, what's the advantage of creating a new vhost char
device? I guess it's for keep the API compatibility?
One benefit is that we can avoid doing vhost ioctls on
VFIO device fd.
Yes, but any benefit from doing this?
It does seem a bit more modular, but it's certainly not a big deal.
Ok, if we go this way, it could be as simple as provide some callback to
vhost, then vhost can just forward the ioctl through parent_ops.
2) For method 2, is there any easy way for user/admin to distinguish e.g
ordinary vfio-mdev for vhost from ordinary vfio-mdev?
I think device-api could be a choice.
Ok.
I saw you introduce
ops matching helper but it's not friendly to management.
The ops matching helper is just to check whether a given
vfio-device is based on a mdev device.
3) A drawback of 1) and 2) is that it must follow vfio_device_ops that
assumes the parameter comes from userspace, it prevents support kernel
virtio drivers.
4) So comes the idea of method 3, since it register a new vhost-mdev driver,
we can use device specific ops instead of VFIO ones, then we can have a
common API between vDPA parent and vhost-mdev/virtio-mdev drivers.
As the above draft shows, this requires introducing a new
VFIO device driver. I think Alex's opinion matters here.
Just to clarify, a new type of mdev driver but provides dummy
vfio_device_ops for VFIO to make container DMA ioctl work.
I see. Thanks! IIUC, you mean we can provide a very tiny
VFIO device driver in drivers/vhost/mdev.c, e.g.:
static int vfio_vhost_mdev_open(void *device_data)
{
if (!try_module_get(THIS_MODULE))
return -ENODEV;
return 0;
}
static void vfio_vhost_mdev_release(void *device_data)
{
module_put(THIS_MODULE);
}
static const struct vfio_device_ops vfio_vhost_mdev_dev_ops = {
.name = "vfio-vhost-mdev",
.open = vfio_vhost_mdev_open,
.release= vfio_vhost_mdev_release,
};
static int vhost_mdev_probe(struct device *dev)
{
struct mdev_device *mdev = to_mdev_device(dev);
... Check the mdev device_id proposed in ...
... https://lkml.org/lkml/2019/9/12/151 ...
return vfio_add_group_dev(dev, _vhost_mdev_dev_ops, mdev);
}
static void vhost_mdev_remove(struct device *dev)
{
vfio_del_group_dev(dev);
}
static struct mdev_driver vhost_mdev_driver = {
.name = "vhost_mdev",
.probe = vhost_mdev_probe,
.remove = vhost_mdev_remove,
};
So we can bind above mdev driver to the virtio-mdev compatible
mdev devices when we want to use vhost-mdev.
After binding above driver to the mdev device, we can setup IOMMU
via VFIO and get VFIO device fd of this mdev device, and pass it
to vhost fd (/dev/vhost-mdev) with a SET_BACKEND ioctl.
Thanks,
Tiwei
Yes, something like this.
Thanks
Thanks
Yes, it is.
Thanks
[random] ec47a799bf: WARNING:at_drivers/char/random.c:#getrandom_wait
FYI, we noticed the following commit (built with gcc-7):
commit: ec47a799bf6bcdb734c5b8571e072226d474aa0a ("[PATCH RFC v4 1/1] random:
WARN on large getrandom() waits and introduce getrandom2()")
url:
https://github.com/0day-ci/linux/commits/Ahmed-S-Darwish/random-WARN-on-large-getrandom-waits-and-introduce-getrandom2/20190919-051815
in testcase: boot
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | e170eb2771 | ec47a799bf |
+--+++
| boot_successes | 4 | 0 |
| boot_failures| 0 | 4 |
| WARNING:at_drivers/char/random.c:#getrandom_wait | 0 | 4 |
| RIP:getrandom_wait | 0 | 4 |
+--+++
If you fix the issue, kindly add following tag
Reported-by: kernel test robot
[ 42.884704] WARNING: CPU: 1 PID: 3042 at drivers/char/random.c:2159
getrandom_wait+0x12d/0x169
[ 42.890882] Modules linked in:
[ 42.893283] CPU: 1 PID: 3042 Comm: getrandom Not tainted
5.3.0-07390-gec47a799bf6bc #11
[ 42.898628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 42.904061] RIP: 0010:getrandom_wait+0x12d/0x169
[ 42.907061] Code: 8b 34 25 00 5d 01 00 44 8b 05 d8 b6 f9 00 8b 96 00 05 00
00 4c 89 e1 48 81 c6 b8 06 00 00 48 c7 c7 a7 d1 39 82 e8 14 08 bc ff <0f> 0b 4c
89 f5 e9 1b ff ff ff ba 01 00 00 00 4c 89 e6 4c 89 ef e8
[ 42.915041] RSP: :c9727ed8 EFLAGS: 00010286
[ 42.917251] RAX: RBX: RCX:
[ 42.919721] RDX: 0001 RSI: 0002 RDI: 82c40b8c
[ 42.98] RBP: 0001 R08: R09: 888bb840
[ 42.925376] R10: c9643c28 R11: c9727d57 R12: 0100
[ 42.928392] R13: ff8f9afc R14: 7fff R15:
[ 42.932129] FS: () GS:88813fd0(0063)
knlGS:f7fb2de4
[ 42.937219] CS: 0010 DS: 002b ES: 002b CR0: 80050033
[ 42.939775] CR2: 0804eff8 CR3: 000123c6a000 CR4: 000406e0
[ 42.942121] Call Trace:
[ 42.943486] ? wait_woken+0x8b/0x8b
[ 42.945035] __se_sys_getrandom+0x60/0x6e
[ 42.946703] do_int80_syscall_32+0x51/0x10c
[ 42.948410] entry_INT80_compat+0x82/0x90
[ 42.950068] ---[ end trace 085d30872d4fa42c ]---
To reproduce:
# build kernel
cd linux
cp config-5.3.0-07390-gec47a799bf6bc .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare
modules_prepare bzImage
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k job-script # job-script is attached in this
email
Thanks,
lkp
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.3.0 Kernel Configuration
#
#
# Compiler: gcc-7 (Debian 7.4.0-13) 7.4.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=70400
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y
CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
# CONFIG_HEADER_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
CONFIG_USELIB=y
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDA
[PATCH v3 4/6] platform/x86: huawei-wmi: Add battery charging thresholds
Control battery charge thresholds through the battery API and driver's
attributes.
Setting battery charging thresholds can introduce a race condition with
MACH-WX9 where two or more threads are trying to read/write values
from/to EC memory.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 1 +
drivers/platform/x86/huawei-wmi.c | 212 ++
2 files changed, 213 insertions(+)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 61bf180d25c7..0659589e46bb 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1305,6 +1305,7 @@ config INTEL_ATOMISP2_PM
config HUAWEI_WMI
tristate "Huawei WMI laptop extras driver"
+ depends on ACPI_BATTERY
depends on ACPI_WMI
depends on INPUT
select INPUT_SPARSEKMAP
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 63e79b5f8282..4ca1a6896766 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -13,7 +14,10 @@
#include
#include
#include
+#include
+#include
#include
+#include
/*
* Huawei WMI GUIDs
@@ -54,11 +58,14 @@ struct huawei_wmi_debug {
};
struct huawei_wmi {
+ bool battery_available;
+
struct huawei_wmi_debug debug;
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
+ struct mutex battery_lock;
struct mutex wmi_lock;
};
@@ -306,6 +313,208 @@ static void huawei_wmi_leds_setup(struct device *dev)
devm_led_classdev_register(dev, >cdev);
}
+/* Battery protection */
+
+static int huawei_wmi_battery_get(int *start, int *end)
+{
+ u8 ret[0x100];
+ int err, i;
+
+ err = huawei_wmi_cmd(BATTERY_THRESH_GET, ret, 0x100);
+ if (err)
+ return err;
+
+ /* Find the last two non-zero values. Return status is ignored. */
+ i = 0x100;
+ do {
+ if (start)
+ *start = ret[i-1];
+ if (end)
+ *end = ret[i];
+ } while (i > 2 && !ret[i--]);
+
+ return 0;
+}
+
+static int huawei_wmi_battery_set(int start, int end)
+{
+ union hwmi_arg arg;
+ int err;
+
+ if (start < 0 || end > 100)
+ return -EINVAL;
+
+ arg.cmd = BATTERY_THRESH_SET;
+ arg.args[2] = start;
+ arg.args[3] = end;
+
+ /* This is an edge case were some models turn battery protection
+* off without changing their thresholds values. We clear the
+* values before turning off protection. Sometimes we need a sleep
delay to
+* make sure these values make their way to EC memory.
+*/
+ if (quirks && quirks->battery_reset && start == 0 && end == 100) {
+ err = huawei_wmi_battery_set(0, 0);
+ if (err)
+ return err;
+
+ msleep(1000);
+ }
+
+ err = huawei_wmi_cmd(arg.cmd, NULL, 0);
+
+ return err;
+}
+
+static ssize_t charge_control_start_threshold_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, start;
+
+ err = huawei_wmi_battery_get(, NULL);
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", start);
+}
+
+static ssize_t charge_control_end_threshold_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, end;
+
+ err = huawei_wmi_battery_get(NULL, );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", end);
+}
+
+static ssize_t charge_control_thresholds_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(, );
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d %d\n", start, end);
+}
+
+static ssize_t charge_control_start_threshold_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(NULL, );
+ if (err)
+ return err;
+
+ if (sscanf(buf, "%d", ) != 1)
+ return -EINVAL;
+
+ err = huawei_wmi_battery_set(start, end);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static ssize_t charge_control_end_threshold_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int err, start, end;
+
+ err = huawei_wmi_battery_get(, NULL);
+ if (err)
+ return err;
+
+ if (sscanf(buf, "%d", ) != 1)
+ return -EINVAL;
+
+ err = huawei_wmi_battery_set(start, end);
+ if
[PATCH v3 6/6] platform/x86: huawei-wmi: Add debugfs support
Add a debugfs interface that can be used to call the WMI management
interface function if available.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 91 +++
1 file changed, 91 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 8fc11a296357..c8f41121160c 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -598,6 +599,94 @@ static void huawei_wmi_fn_lock_exit(struct device *dev)
device_remove_file(dev, _attr_fn_lock_state);
}
+/* debugfs */
+
+static void huawei_wmi_debugfs_call_dump(struct seq_file *m, void *data,
+ union acpi_object *obj)
+{
+ struct huawei_wmi *huawei = m->private;
+ int i;
+
+ switch (obj->type) {
+ case ACPI_TYPE_INTEGER:
+ seq_printf(m, "0x%llx", obj->integer.value);
+ break;
+ case ACPI_TYPE_STRING:
+ seq_printf(m, "\"%*s\"", obj->string.length,
obj->string.pointer);
+ break;
+ case ACPI_TYPE_BUFFER:
+ seq_puts(m, "{");
+ for (i = 0; i < obj->buffer.length; i++) {
+ seq_printf(m, "0x%02x", obj->buffer.pointer[i]);
+ if (i < obj->buffer.length - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "}");
+ break;
+ case ACPI_TYPE_PACKAGE:
+ seq_puts(m, "[");
+ for (i = 0; i < obj->package.count; i++) {
+ huawei_wmi_debugfs_call_dump(m, huawei,
>package.elements[i]);
+ if (i < obj->package.count - 1)
+ seq_puts(m, ",");
+ }
+ seq_puts(m, "]");
+ break;
+ default:
+ dev_err(>pdev->dev, "Unexpected obj type, got %d\n",
obj->type);
+ return;
+ }
+}
+
+static int huawei_wmi_debugfs_call_show(struct seq_file *m, void *data)
+{
+ struct huawei_wmi *huawei = m->private;
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ int err;
+
+ in.length = sizeof(u64);
+ in.pointer = >debug.arg;
+
+ err = huawei_wmi_call(, );
+ if (err)
+ return err;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_debugfs_call;
+ }
+
+ huawei_wmi_debugfs_call_dump(m, huawei, obj);
+
+fail_debugfs_call:
+ kfree(out.pointer);
+ return err;
+}
+
+DEFINE_SHOW_ATTRIBUTE(huawei_wmi_debugfs_call);
+
+static void huawei_wmi_debugfs_setup(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ huawei->debug.root = debugfs_create_dir("huawei-wmi", NULL);
+
+ debugfs_create_x64("arg", 0644, huawei->debug.root,
+ >debug.arg);
+ debugfs_create_file("call", 0400,
+ huawei->debug.root, huawei, _wmi_debugfs_call_fops);
+}
+
+static void huawei_wmi_debugfs_exit(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ debugfs_remove_recursive(huawei->debug.root);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -723,6 +812,7 @@ static int huawei_wmi_probe(struct platform_device *pdev)
huawei_wmi_leds_setup(>dev);
huawei_wmi_fn_lock_setup(>dev);
huawei_wmi_battery_setup(>dev);
+ huawei_wmi_debugfs_setup(>dev);
}
return 0;
@@ -740,6 +830,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
}
if (wmi_has_guid(HWMI_METHOD_GUID)) {
+ huawei_wmi_debugfs_exit(>dev);
huawei_wmi_battery_exit(>dev);
huawei_wmi_fn_lock_exit(>dev);
}
--
2.21.0
[PATCH v3 2/6] platform/x86: huawei-wmi: Add quirks and module parameters
Introduce quirks and module parameters. 3 quirks are added:
1. Fixes reporting brightness keys twice since it's already handled by
acpi-video.
2. Some models need a short delay when setting battery thresholds to
prevent a race condition when two processes read/write. (will be used later)
3. Matebook X (2017) handles micmute led through the "legacy" interface
which is not currently implemented. Use ACPI EC method to control
this led. (will be used later)
2 module parameters are added to enable this short delay and/or report
brightness keys through this driver.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 77 +++
1 file changed, 77 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 9496ea3c78b5..97ff3d868765 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -22,7 +23,21 @@
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+struct quirk_entry {
+ bool battery_reset;
+ bool ec_micmute;
+ bool report_brightness;
+};
+
+static struct quirk_entry *quirks;
+
+struct huawei_wmi_debug {
+ struct dentry *root;
+ u64 arg;
+};
+
struct huawei_wmi {
+ struct huawei_wmi_debug debug;
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
@@ -49,6 +64,58 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_END,0 }
};
+static bool battery_reset;
+static bool report_brightness;
+
+module_param(battery_reset, bool, 0444);
+MODULE_PARM_DESC(battery_reset,
+ "Reset battery charge values to (0-0) before disabling it using
(0-100)");
+module_param(report_brightness, bool, 0444);
+MODULE_PARM_DESC(report_brightness,
+ "Report brightness keys.");
+
+/* Quirks */
+
+static int __init dmi_matched(const struct dmi_system_id *dmi)
+{
+ quirks = dmi->driver_data;
+ return 1;
+}
+
+static struct quirk_entry quirk_unknown = {
+};
+
+static struct quirk_entry quirk_battery_reset = {
+ .battery_reset = true,
+};
+
+static struct quirk_entry quirk_matebook_x = {
+ .ec_micmute = true,
+ .report_brightness = true,
+};
+
+static const struct dmi_system_id huawei_quirks[] = {
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MACH-WX9",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "MACH-WX9"),
+ },
+ .driver_data = _battery_reset
+ },
+ {
+ .callback = dmi_matched,
+ .ident = "Huawei MateBook X",
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HUAWEI"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HUAWEI MateBook X")
+ },
+ .driver_data = _matebook_x
+ },
+ { }
+};
+
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
@@ -139,6 +206,11 @@ static void huawei_wmi_process_key(struct input_dev *idev,
int code)
return;
}
+ if (quirks && !quirks->report_brightness &&
+ (key->sw.code == KEY_BRIGHTNESSDOWN ||
+ key->sw.code == KEY_BRIGHTNESSUP))
+ return;
+
sparse_keymap_report_entry(idev, key, 1, true);
}
@@ -253,6 +325,11 @@ static __init int huawei_wmi_init(void)
if (!huawei_wmi)
return -ENOMEM;
+ quirks = _unknown;
+ dmi_check_system(huawei_quirks);
+ quirks->battery_reset |= battery_reset;
+ quirks->report_brightness |= report_brightness;
+
err = platform_driver_register(_wmi_driver);
if (err)
goto pdrv_err;
--
2.21.0
[PATCH v3 3/6] platform/x86: huawei-wmi: Implement huawei wmi management
Huawei Matebook laptops come with a WMI management interface that can
control various aspects of the device. This interface is also found on
the old Matebook X released in 2017.
Use that to control the mic mute LED.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 217 +-
1 file changed, 180 insertions(+), 37 deletions(-)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 97ff3d868765..63e79b5f8282 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -11,18 +11,35 @@
#include
#include
#include
+#include
#include
#include
/*
* Huawei WMI GUIDs
*/
+#define HWMI_METHOD_GUID "ABBC0F5B-8EA1-11D1-A000-C9062910"
#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
+/* HWMI commands */
+
+enum {
+ BATTERY_THRESH_GET = 0x1103, /* \GBTT */
+ BATTERY_THRESH_SET = 0x1003, /* \SBTT */
+ FN_LOCK_GET = 0x0604, /* \GFRS */
+ FN_LOCK_SET = 0x0704, /* \SFRS */
+ MICMUTE_LED_SET = 0x0b04, /* \SMLS */
+};
+
+union hwmi_arg {
+ u64 cmd;
+ u8 args[8];
+};
+
struct quirk_entry {
bool battery_reset;
bool ec_micmute;
@@ -41,8 +58,8 @@ struct huawei_wmi {
struct input_dev *idev[2];
struct led_classdev cdev;
struct platform_device *pdev;
- acpi_handle handle;
- char *acpi_method;
+
+ struct mutex wmi_lock;
};
struct huawei_wmi *huawei_wmi;
@@ -116,52 +133,168 @@ static const struct dmi_system_id huawei_quirks[] = {
{ }
};
+/* Utils */
+
+static int huawei_wmi_call(struct acpi_buffer *in, struct acpi_buffer *out)
+{
+ acpi_status status;
+
+ mutex_lock(_wmi->wmi_lock);
+ status = wmi_evaluate_method(HWMI_METHOD_GUID, 0, 1, in, out);
+ mutex_unlock(_wmi->wmi_lock);
+ if (ACPI_FAILURE(status)) {
+ dev_err(_wmi->pdev->dev, "Failed to evaluate wmi
method\n");
+ return -ENODEV;
+ }
+
+ return 0;
+}
+
+/* HWMI takes a 64 bit input and returns either a package with 2 buffers, one
of
+ * 4 bytes and the other of 256 bytes, or one buffer of size 0x104 (260) bytes.
+ * The first 4 bytes are ignored, we ignore the first 4 bytes buffer if we got
a
+ * package, or skip the first 4 if a buffer of 0x104 is used. The first byte of
+ * the remaining 0x100 sized buffer has the return status of every call. In
case
+ * the return status is non-zero, we return -ENODEV but still copy the returned
+ * buffer to the given buffer parameter (buf).
+ */
+static int huawei_wmi_cmd(u64 arg, u8 *buf, size_t buflen)
+{
+ struct acpi_buffer out = { ACPI_ALLOCATE_BUFFER, NULL };
+ struct acpi_buffer in;
+ union acpi_object *obj;
+ size_t len;
+ int err, i;
+
+ in.length = sizeof(arg);
+ in.pointer =
+
+ /* Some models require calling HWMI twice to execute a command. We
evaluate
+* HWMI and if we get a non-zero return status we evaluate it again.
+*/
+ for (i = 0; i < 2; i++) {
+ err = huawei_wmi_call(, );
+ if (err)
+ goto fail_cmd;
+
+ obj = out.pointer;
+ if (!obj) {
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ switch (obj->type) {
+ /* Models that implement both "legacy" and HWMI tend to return
a 0x104
+* sized buffer instead of a package of 0x4 and 0x100 buffers.
+*/
+ case ACPI_TYPE_BUFFER:
+ if (obj->buffer.length == 0x104) {
+ // Skip the first 4 bytes.
+ obj->buffer.pointer += 4;
+ len = 0x100;
+ } else {
+ dev_err(_wmi->pdev->dev, "Bad buffer
length, got %d\n", obj->buffer.length);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ break;
+ /* HWMI returns a package with 2 buffer elements, one of 4
bytes and the
+* other is 256 bytes.
+*/
+ case ACPI_TYPE_PACKAGE:
+ if (obj->package.count != 2) {
+ dev_err(_wmi->pdev->dev, "Bad package
count, got %d\n", obj->package.count);
+ err = -EIO;
+ goto fail_cmd;
+ }
+
+ obj = >package.elements[1];
+ if (obj->type != ACPI_TYPE_BUFFER) {
+
[PATCH v3 5/6] platform/x86: huawei-wmi: Add fn-lock support
Huawei Matebook laptops uses Fn key and toggle to access F1-F12 keys.
Along with that, there is this feature called fn-lock that inverts the
behavior of this Fn key and the F1-F12 row.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/huawei-wmi.c | 85 +++
1 file changed, 85 insertions(+)
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 4ca1a6896766..8fc11a296357 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -59,6 +59,7 @@ struct huawei_wmi_debug {
struct huawei_wmi {
bool battery_available;
+ bool fn_lock_available;
struct huawei_wmi_debug debug;
struct input_dev *idev[2];
@@ -515,6 +516,88 @@ static void huawei_wmi_battery_exit(struct device *dev)
}
}
+/* Fn lock */
+
+static int huawei_wmi_fn_lock_get(int *on)
+{
+ u8 ret[0x100] = { 0 };
+ int err, i;
+
+ err = huawei_wmi_cmd(FN_LOCK_GET, ret, 0x100);
+ if (err)
+ return err;
+
+ /* Find the first non-zero value. Return status is ignored. */
+ i = 1;
+ do {
+ if (on)
+ *on = ret[i] - 1; // -1 undefined, 0 off, 1 on.
+ } while (i < 0x100 && !ret[i++]);
+
+ return 0;
+}
+
+static int huawei_wmi_fn_lock_set(int on)
+{
+ union hwmi_arg arg;
+
+ arg.cmd = FN_LOCK_SET;
+ arg.args[2] = on + 1; // 0 undefined, 1 off, 2 on.
+
+ return huawei_wmi_cmd(arg.cmd, NULL, 0);
+}
+
+static ssize_t fn_lock_state_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ int err, on;
+
+ err = huawei_wmi_fn_lock_get();
+ if (err)
+ return err;
+
+ return sprintf(buf, "%d\n", on);
+}
+
+static ssize_t fn_lock_state_store(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t size)
+{
+ int on, err;
+
+ if (kstrtoint(buf, 10, ) ||
+ on < 0 || on > 1)
+ return -EINVAL;
+
+ err = huawei_wmi_fn_lock_set(on);
+ if (err)
+ return err;
+
+ return size;
+}
+
+static DEVICE_ATTR_RW(fn_lock_state);
+
+static void huawei_wmi_fn_lock_setup(struct device *dev)
+{
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
+
+ huawei->fn_lock_available = true;
+ if (huawei_wmi_fn_lock_get(NULL)) {
+ huawei->fn_lock_available = false;
+ return;
+ }
+
+ device_create_file(dev, _attr_fn_lock_state);
+}
+
+static void huawei_wmi_fn_lock_exit(struct device *dev)
+{
+ if (huawei_wmi->fn_lock_available)
+ device_remove_file(dev, _attr_fn_lock_state);
+}
+
/* Input */
static void huawei_wmi_process_key(struct input_dev *idev, int code)
@@ -638,6 +721,7 @@ static int huawei_wmi_probe(struct platform_device *pdev)
mutex_init(_wmi->battery_lock);
huawei_wmi_leds_setup(>dev);
+ huawei_wmi_fn_lock_setup(>dev);
huawei_wmi_battery_setup(>dev);
}
@@ -657,6 +741,7 @@ static int huawei_wmi_remove(struct platform_device *pdev)
if (wmi_has_guid(HWMI_METHOD_GUID)) {
huawei_wmi_battery_exit(>dev);
+ huawei_wmi_fn_lock_exit(>dev);
}
return 0;
--
2.21.0
[PATCH v3 1/6] platform/x86: huawei-wmi: Move to platform driver
Move from WMI driver to platform driver. This move is necessary since
the driver is no longer a hotkeys driver only. Platform driver makes it
easier for users to access sysfs attributes under (i.e.
/sys/devices/platform/huawei-wmi) compared to wmi driver.
Use WMI device UID, AMW0 has a UID of HWMI. WMI0 is the device name
and doesn't have a UID so keep it as it is.
Signed-off-by: Ayman Bagabas
---
drivers/platform/x86/Kconfig | 7 +-
drivers/platform/x86/huawei-wmi.c | 226 --
2 files changed, 156 insertions(+), 77 deletions(-)
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 1b67bb578f9f..61bf180d25c7 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -1304,7 +1304,7 @@ config INTEL_ATOMISP2_PM
will be called intel_atomisp2_pm.
config HUAWEI_WMI
- tristate "Huawei WMI hotkeys driver"
+ tristate "Huawei WMI laptop extras driver"
depends on ACPI_WMI
depends on INPUT
select INPUT_SPARSEKMAP
@@ -1313,9 +1313,8 @@ config HUAWEI_WMI
select LEDS_TRIGGER_AUDIO
select NEW_LEDS
help
- This driver provides support for Huawei WMI hotkeys.
- It enables the missing keys and adds support to the micmute
- LED found on some of these laptops.
+ This driver provides support for Huawei WMI hotkeys, battery charge
+ control, fn-lock, mic-mute LED, and other extra features.
To compile this driver as a module, choose M here: the module
will be called huawei-wmi.
diff --git a/drivers/platform/x86/huawei-wmi.c
b/drivers/platform/x86/huawei-wmi.c
index 195a7f3638cb..9496ea3c78b5 100644
--- a/drivers/platform/x86/huawei-wmi.c
+++ b/drivers/platform/x86/huawei-wmi.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Huawei WMI hotkeys
+ * Huawei WMI laptop extras driver
*
* Copyright (C) 2018 Ayman Bagabas
*/
@@ -10,23 +10,28 @@
#include
#include
#include
+#include
#include
/*
* Huawei WMI GUIDs
*/
-#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
-#define AMW0_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+#define HWMI_EVENT_GUID "ABBC0F5C-8EA1-11D1-A000-C9062910"
+/* Legacy GUIDs */
#define WMI0_EXPENSIVE_GUID "39142400-C6A3-40fa-BADB-8A2652834100"
+#define WMI0_EVENT_GUID "59142400-C6A3-40fa-BADB-8A2652834100"
-struct huawei_wmi_priv {
- struct input_dev *idev;
+struct huawei_wmi {
+ struct input_dev *idev[2];
struct led_classdev cdev;
+ struct platform_device *pdev;
acpi_handle handle;
char *acpi_method;
};
+struct huawei_wmi *huawei_wmi;
+
static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x281, { KEY_BRIGHTNESSDOWN } },
{ KE_KEY,0x282, { KEY_BRIGHTNESSUP } },
@@ -37,7 +42,7 @@ static const struct key_entry huawei_wmi_keymap[] = {
{ KE_KEY,0x289, { KEY_WLAN } },
// Huawei |M| key
{ KE_KEY,0x28a, { KEY_CONFIG } },
- // Keyboard backlight
+ // Keyboard backlit
{ KE_IGNORE, 0x293, { KEY_KBDILLUMTOGGLE } },
{ KE_IGNORE, 0x294, { KEY_KBDILLUMUP } },
{ KE_IGNORE, 0x295, { KEY_KBDILLUMUP } },
@@ -47,7 +52,7 @@ static const struct key_entry huawei_wmi_keymap[] = {
static int huawei_wmi_micmute_led_set(struct led_classdev *led_cdev,
enum led_brightness brightness)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(led_cdev->dev->parent);
+ struct huawei_wmi *huawei = dev_get_drvdata(led_cdev->dev->parent);
acpi_status status;
union acpi_object args[3];
struct acpi_object_list arg_list = {
@@ -58,52 +63,53 @@ static int huawei_wmi_micmute_led_set(struct led_classdev
*led_cdev,
args[0].type = args[1].type = args[2].type = ACPI_TYPE_INTEGER;
args[1].integer.value = 0x04;
- if (strcmp(priv->acpi_method, "SPIN") == 0) {
+ if (strcmp(huawei->acpi_method, "SPIN") == 0) {
args[0].integer.value = 0;
args[2].integer.value = brightness ? 1 : 0;
- } else if (strcmp(priv->acpi_method, "WPIN") == 0) {
+ } else if (strcmp(huawei->acpi_method, "WPIN") == 0) {
args[0].integer.value = 1;
args[2].integer.value = brightness ? 0 : 1;
} else {
return -EINVAL;
}
- status = acpi_evaluate_object(priv->handle, priv->acpi_method,
_list, NULL);
+ status = acpi_evaluate_object(huawei->handle, huawei->acpi_method,
_list, NULL);
if (ACPI_FAILURE(status))
return -ENXIO;
return 0;
}
-static int huawei_wmi_leds_setup(struct wmi_device *wdev)
+static void huawei_wmi_leds_setup(struct device *dev)
{
- struct huawei_wmi_priv *priv = dev_get_drvdata(>dev);
+ struct huawei_wmi *huawei = dev_get_drvdata(dev);
- priv->handle = ec_get_handle();
- if
[PATCH v3 0/6] platform/x86: Huawei WMI laptop extras driver
Changes in v3: * Kconfig changes * Fix NULL cast to int warning. * Add ACPI_BATTERY as a dependency. Changes in v2: * Use battery charge control API. This patch series introduce changes to huawei-wmi driver that includes: * Move to platform driver * Implement driver quirks and parameters * Implement WMI management interface * Add micmute LED support through WMI * Add battery charging protection support through WMI * Add fn-lock support through WMI * Add a debugfs interface to WMI # Move to platform driver The current driver offers hotkeys and micmute led support only. With these changes, a platform driver makes more sense since it handles these changes pretty nicely. # Implement WMI management interface Huawei Matebook laptops come with two WMI interfaces. The first being WMI0 which is considered "legacy" and AFAIK only found on the Matebook X released in 2017. The second has a UID of "HWMI" and is found in pretty much all models with a slight difference in implementation except for the Matebook X (2017). Since this model has two interfaces, some aspects are controlled through the legacy interface and some through the other interface. Currently, the legacy interface is not fully implemented and is only used for hotkeys and further debugging has to be done. The WMI interface takes a 64 bit integer, although uses 32 bits most of the time, and returns a 256-260 bytes buffer consists of either one ACPI buffer of 260 bytes, in the case of Matebook X (2017), or one ACPI package of two buffers, one with 4 bytes, and the other with 256 bytes. We only care about the latter 256 buffer in both cases since the 4 bytes always return zeros. The first byte of this 256 buffer always has the return status where 1 indicated error. Some models require calling the WMI interface twice to execute a command. # Add micmute LED support through WMI After implementing the WMI interface, micmute LED can be controlled easily. Models with the legacy interface fall back to ACPI EC method control since the legacy interface is not implemented. # Add battery charging protection support through WMI Most models, that has the WMI interface, are capable of battery protection where it can control battery charging thresholds and limits charging the battery to certain values. # Add fn-lock support through WMI The behavior of hotkeys is not the same among all models. Some models require fn-lock to do things like `Ctrl-Ins` or `Alt-PrtSc`. By default, hotkeys behave as special keys (media keys, Ins, etc), but if a modifier is used (ctrl, alt, shift) these keys behave as F1-F12 keys. If the Fn key is toggled on, the hotkeys with or without a modifier, behave as F1-F12 keys. This makes it impossible to use a modifier and `PrtSc` or `Ins`. Now, some models fix this by excluding `PrtSc` and `Ins` keys from being treated as F11 and F12 keys with the use of a modifier. However, some models do not, and fixes this by the so called fn-lock. Fn-lock inverts the behavior of the top row from special keys to F1-F12 keys. So a modifier and a special key would be possible which make things like `Alt-Ins` possible. Now, with fn-lock we would have 4 modes: * Fn-key off & fn-lock off - hotkeys treated as special keys using a modifier gives F1-F12 keys. * Fn-key on & fn-lock off - hotkeys treated as F1-F12 keys and using a modifier gives F1-F12. * Fn-key off & fn-lock on - hotkeys are treated as F1-F12 keys and using a modifier gives special keys. * Fn-key on & fn-lock on - hotkeys are treated as special keys and using a modifier gives special keys. # Implement driver quirks and parameters The driver introduces 3 quirks and 2 parameters that can change the driver's behavior. These quirks being as: 1. Fixes reporting brightness keys twice since it's already handled by acpi-video. 2. Some models need a short delay when setting battery thresholds to prevent a race condition when two processes read/write. 3. Matebook X (2017) handles micmute led through the "legacy" interface which is not currently implemented. Use ACPI EC method to control this led. and the 2 parameters can enforce the behavior of quirk 1 & 2. # Add a debugfs interface to WMI An interface to the WMI management interface that allows easier debugging. Ayman Bagabas (6): platform/x86: huawei-wmi: Move to platform driver platform/x86: huawei-wmi: Add quirks and module parameters platform/x86: huawei-wmi: Implement huawei wmi management platform/x86: huawei-wmi: Add battery charging thresholds platform/x86: huawei-wmi: Add fn-lock support platform/x86: huawei-wmi: Add debugfs support drivers/platform/x86/Kconfig | 1 + drivers/platform/x86/huawei-wmi.c | 872 ++ 2 files changed, 781 insertions(+), 92 deletions(-) base-commit: 288b9117de5cc1b7fb80f54b7c17deed6f018641 -- 2.21.0
[PATCH] NFSv4: fix memory leak if nfs4_begin_drain_session fails
In nfs4_try_migration, if nfs4_begin_drain_session fails the allocated
memory should be released.
Signed-off-by: Navid Emamdoost
---
fs/nfs/nfs4state.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c
index cad4e064b328..124649f12067 100644
--- a/fs/nfs/nfs4state.c
+++ b/fs/nfs/nfs4state.c
@@ -2096,7 +2096,7 @@ static int nfs4_try_migration(struct nfs_server *server,
const struct cred *cred
status = nfs4_begin_drain_session(clp);
if (status != 0)
- return status;
+ goto out;
status = nfs4_replace_transport(server, locations);
if (status != 0) {
--
2.17.1
Re: [PATCH] ionic: remove useless return code
On Wed, 18 Sep 2019 13:46:34 -0700, Shannon Nelson wrote:
> On 9/18/19 12:57 PM, Arnd Bergmann wrote:
> > The debugfs function was apparently changed from returning an error code
> > to a void return, but the return code left in place, causing a warning
> > from clang:
> >
> > drivers/net/ethernet/pensando/ionic/ionic_debugfs.c:60:37: error:
> > expression result unused [-Werror,-Wunused-value]
> > ionic, _fops) ? 0 : -EOPNOTSUPP;
> > ^~~
> >
> > Fixes: fbfb8031533c ("ionic: Add hardware init and device commands")
> > Signed-off-by: Arnd Bergmann
> > ---
> > drivers/net/ethernet/pensando/ionic/ionic_debugfs.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
> > b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
> > index 7afc4a365b75..bc03cecf80cc 100644
> > --- a/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
> > +++ b/drivers/net/ethernet/pensando/ionic/ionic_debugfs.c
> > @@ -57,7 +57,7 @@ DEFINE_SHOW_ATTRIBUTE(identity);
> > void ionic_debugfs_add_ident(struct ionic *ionic)
> > {
> > debugfs_create_file("identity", 0400, ionic->dentry,
> > - ionic, _fops) ? 0 : -EOPNOTSUPP;
> > + ionic, _fops);
> > }
> >
> > void ionic_debugfs_add_sizes(struct ionic *ionic)
>
> This has just recently been addressed by Nathan Chancellor
>
Yup, should be in the net tree now.
> Either way,
>
> Acked-by: Shannon Nelson
Thanks for quick reviews!
Re: [PATCH] ionic: Remove unnecessary ternary operator in ionic_debugfs_add_ident
On Tue, 17 Sep 2019 16:26:16 -0700, Nathan Chancellor wrote:
> clang warns:
>
> ../drivers/net/ethernet/pensando/ionic/ionic_debugfs.c:60:37: warning:
> expression result unused [-Wunused-value]
> ionic, _fops) ? 0 : -EOPNOTSUPP;
> ^~~
> 1 warning generated.
>
> The return value of debugfs_create_file does not need to be checked [1]
> and the function returns void so get rid of the ternary operator, it is
> unnecessary.
>
> [1]: https://lore.kernel.org/linux-mm/20150815160730.gb25...@kroah.com/
>
> Fixes: fbfb8031533c ("ionic: Add hardware init and device commands")
> Link: https://github.com/ClangBuiltLinux/linux/issues/658
> Signed-off-by: Nathan Chancellor
Applied, thank you!
Re: build_path_from_dentry_optional_prefix() may schedule from invalid context
ср, 28 авг. 2019 г. в 22:02, Sergey Senozhatsky
:
>
> Hello,
>
> Looking at commit "cifs: create a helper to find a writeable handle
> by path name":
>
> ->open_file_lock scope is atomic context, while build_path_from_dentry()
> can schedule - kmalloc(GFP_KERNEL)
>
>spin_lock(>open_file_lock);
>list_for_each(tmp, >openFileList) {
>cfile = list_entry(tmp, struct cifsFileInfo,
> tlist);
>full_path = build_path_from_dentry(cfile->dentry);
>if (full_path == NULL) {
>spin_unlock(>open_file_lock);
>return -ENOMEM;
>}
>if (strcmp(full_path, name)) {
>kfree(full_path);
>continue;
>}
>kfree(full_path);
>
>cinode = CIFS_I(d_inode(cfile->dentry));
>spin_unlock(>open_file_lock);
>return cifs_get_writable_file(cinode, 0, ret_file);
>}
>
>spin_unlock(>open_file_lock);
>
> Additionally, kfree() can (and should) be done outside of
> ->open_file_lock scope.
>
> -ss
Good catch. I think we should have another version of
build_path_from_dentry() which takes pre-allocated (probably on stack)
full_path as an argument. This would allow us to avoid allocations
under the spin lock.
--
Best regards,
Pavel Shilovsky
Re: [RFC {net,iproute2}-next 0/2] Introduce an eBPF hookpoint for tx queue selection in the XPS (Transmit Packet Steering) code.
On Thu, Sep 19, 2019 at 3:45 PM Matthew Cover wrote:
>
> WORK IN PROGRESS:
> * bpf program loading works!
> * txq steering via bpf program return code works!
> * bpf program unloading not working.
> * bpf program attached query not working.
>
> This patch set provides a bpf hookpoint with goals similar to, but a more
> generic implementation than, TUNSETSTEERINGEBPF; userspace supplied tx queue
> selection policy.
>
> TUNSETSTEERINGEBPF is a useful bpf hookpoint, but has some drawbacks.
>
> First, it only works on tun/tap devices.
>
> Second, there is no way in the current TUNSETSTEERINGEBPF implementation
> to bail out or load a noop bpf prog and fallback to the no prog tx queue
> selection method.
>
> Third, the TUNSETSTEERINGEBPF interface seems to require possession of
> existing
> or creation of new queues/fds.
>
> This most naturally fits in the "wire" implementation since possession of fds
> is ensured. However, it also means the various "wire" implementations (e.g.
> qemu) have to all be made aware of TUNSETSTEERINGEBPF and expose an interface
> to load/unload a bpf prog (or provide a mechanism to pass an fd to another
> program).
>
> Alternatively, you can spin up an extra queue and immediately disable via
> IFF_DETACH_QUEUE, but this seems unsafe; packets could be enqueued to this
> extra file descriptor which is part of our bpf prog loader, not our "wire".
>
> Placing this in the XPS code and leveraging iproute2 and rtnetlink to provide
> our bpf prog loader in a similar manner to xdp gives us a nice way to separate
> the tap "wire" and the loading of tx queue selection policy. It also lets us
> use this hookpoint for any device traversing XPS.
>
> This patch only introduces the new hookpoint to the XPS code and will not yet
> be used by tun/tap devices using the intree tun.ko (which implements an
> .ndo_select_queue and does not traverse the XPS code).
>
> In a future patch set, we can optionally refactor tun.ko to traverse this call
> to bpf_prog_run_clear_cb() and bpf prog storage. tun/tap devices could then
> leverage iproute2 as a generic loader. The TUNSETSTEERINGEBPF interface could
> at this point be optionally deprecated/removed.
>
> Both patches in this set have been tested using a rebuilt tun.ko with no
> .ndo_select_queue.
>
> sed -i '/\.ndo_select_queue.*=/d' drivers/net/tun.c
>
> The tap device was instantiated using tap_mq_pong.c, supporting scripts, and
> wrapping service found here:
>
> https://github.com/stackpath/rxtxcpu/tree/v1.2.6/helpers
>
> The bpf prog source and test scripts can be found here:
>
> https://github.com/werekraken/xps_ebpf
>
> In nstxq, netsniff-ng using PACKET_FANOUT_QM is leveraged to check the
> queue_mapping.
>
> With no prog loaded, the tx queue selection is adhering our xps_cpus
> configuration.
>
> [vagrant@localhost ~]$ grep . /sys/class/net/tap0/queues/tx-*/xps_cpus;
> ./nstxq; sudo timeout 1 cat /sys/kernel/debug/tracing/trace_pipe;
> /sys/class/net/tap0/queues/tx-0/xps_cpus:1
> /sys/class/net/tap0/queues/tx-1/xps_cpus:2
> cpu0: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.146 ms
> cpu0: qm0: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
> cpu1: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.121 ms
> cpu1: qm1: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
>
> With a return 0 bpg prog, our tx queue is 0 (despite xps_cpus).
>
> [vagrant@localhost ~]$ sudo ip link set dev tap0 xps obj hello0.o sec hello
> && { ./nstxq; sudo timeout 1 cat /sys/kernel/debug/tracing/trace_pipe; }
> cpu0: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.160 ms
> cpu0: qm0: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
> cpu1: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.124 ms
> cpu1: qm0: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
> ping-4852 [000] 2691.633260: 0: xps (RET 0): Hello,
> World!
> ping-4869 [001] 2695.753588: 0: xps (RET 0): Hello,
> World!
>
> With a return 1 bpg prog, our tx queue is 1.
>
> [vagrant@localhost ~]$ sudo ip link set dev tap0 xps obj hello1.o sec hello
> && { ./nstxq; sudo timeout 1 cat /sys/kernel/debug/tracing/trace_pipe; }
> cpu0: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.193 ms
> cpu0: qm1: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
> cpu1: ping: 64 bytes from 169.254.254.1: icmp_seq=1 ttl=64 time=0.135 ms
> cpu1: qm1: > tap0 98 Unknown => Unknown IPv4 169.254.254.2/169.254.254.1
> Len 84 Type 8 Code 0
> ping-4894 [000] 2710.652080: 0: xps (RET 1): Hello,
> World!
> ping-4911 [001] 2714.774608: 0: xps (RET 1): Hello,
> World!
>
> With a return 2 bpg prog, our tx queue is 0 (we only have 2 tx queues).
>
>
Re: [PATCH 1/2] x86,sched: Add support for frequency invariance
On Tue, 2019-09-17 at 16:27 +0200, Giovanni Gherdovich wrote: > Hello Srinivas, > > On Fri, 2019-09-13 at 15:52 -0700, Srinivas Pandruvada wrote: > > On Mon, 2019-09-09 at 04:42 +0200, Giovanni Gherdovich wrote: > > > > ... > > > > > + > > > +/* > > > + * APERF/MPERF frequency ratio computation. > > > + * > > > + * The scheduler wants to do frequency invariant accounting and > > > needs a <1 > > > + * ratio to account for the 'current' frequency, corresponding > > > to > > > + * freq_curr / freq_max. > > > > I thought this is no longer the restriction and Vincent did some > > work > > to remove this restriction. > > If you're referring to the patch > > 23127296889f "sched/fair: Update scale invariance of PELT" > > merged in v5.2, I'm familiar with that and from my understanding you > still > want a <1 scaling factor. This is my recalling of the patch: > > Vincent was studying some synthetic traces and realized that util_avg > reported > by PELT didn't quite match the result you'd get computing the formula > with pen > and paper (theoretical value). To address this he changed where the > scaling > factor is applied in the PELT formula. > > At some point when accumulating the PELT sums, you'll have to measure > the time > 'delta' since you last updated PELT. What we have after Vincent's > change is > that this time length 'delta' gets itself scaled by the > freq_curr/freq_max > ratio: > > delta = time since last PELT update > delta *= freq_percent > > In this way time goes at "wall clock speed" only when you're running > at max > capacitiy, and goes "slower" (from the PELT point of view) if we're > running at > a lower frequency. I don't think Vincent had in mind a faster-than- > wall-clock > PELT time (which you'd get w/ freq_percent>1). > > Speaking of which, Srinivas, do you have any opinion and/or > requirement about > this? I confusely remember Peter Zijlstra saying (more than a year > ago, now) > that you would like an unclipped freq_curr/freq_max ratio, and may > not be > happy with this patch clipping it to 1 when freq_curr > > 4_cores_turbo. If > that's the case, could you elaborate on this? > Ignore that if it doesn't make sense, I may be mis-remembering. I was thinking of power efficiency use case particularly for Atom like platforms, 1C max as you observed is more efficient. But now sched deadline code is using arch_scale_freq_capacity(() to calculate dl_se->runtime, where closer to deterministic value with all cores, may be better, which will be scaled with base_freq. Thanks, Srinivas
Re: [PATCH V3 2/4] ASoC: fsl_asrc: update supported sample format
On Thu, Sep 19, 2019 at 08:11:40PM +0800, Shengjiu Wang wrote:
> The ASRC support 24bit/16bit/8bit input width, which is
> data width, not slot width.
>
> For the S20_3LE format, the data with is 20bit, slot width
> is 24bit, if we set ASRMCR1n.IWD to be 24bits, the result
> is the volume is lower than expected, it likes 24bit data
> right shift 4 bits
>
> So replace S20_3LE with S24_3LE in supported list and add S8
> format in TX supported list
>
> Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
> ---
> sound/soc/fsl/fsl_asrc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
> index 4d3804a1ea55..584badf956d2 100644
> --- a/sound/soc/fsl/fsl_asrc.c
> +++ b/sound/soc/fsl/fsl_asrc.c
> @@ -624,7 +624,7 @@ static int fsl_asrc_dai_probe(struct snd_soc_dai *dai)
>
> #define FSL_ASRC_FORMATS (SNDRV_PCM_FMTBIT_S24_LE | \
>SNDRV_PCM_FMTBIT_S16_LE | \
> - SNDRV_PCM_FMTBIT_S20_3LE)
> + SNDRV_PCM_FMTBIT_S24_3LE)
>
> static struct snd_soc_dai_driver fsl_asrc_dai = {
> .probe = fsl_asrc_dai_probe,
> @@ -635,7 +635,8 @@ static struct snd_soc_dai_driver fsl_asrc_dai = {
> .rate_min = 5512,
> .rate_max = 192000,
> .rates = SNDRV_PCM_RATE_KNOT,
> - .formats = FSL_ASRC_FORMATS,
> + .formats = FSL_ASRC_FORMATS |
> +SNDRV_PCM_FMTBIT_S8,
> },
> .capture = {
> .stream_name = "ASRC-Capture",
> --
> 2.21.0
>
Re: [PATCH RFC v4 1/1] random: WARN on large getrandom() waits and introduce getrandom2()
20.09.2019 03:23, Alexander E. Patrakov пишет: 20.09.2019 02:47, Linus Torvalds пишет: On Thu, Sep 19, 2019 at 1:45 PM Alexander E. Patrakov wrote: This already resembles in-kernel haveged (except that it doesn't credit entropy), and Willy Tarreau said "collect the small entropy where it is, period" today. So, too many people touched upon the topic in one day, and therefore I'll bite. I'm one of the people who aren't entirely convinced by the jitter entropy - I definitely believe it exists, I just am not necessarily convinced about the actual entropy calculations. So while I do think we should take things like the cycle counter into account just because I think it's a a useful way to force some noise, I am *not* a huge fan of the jitter entropy driver either, because of the whole "I'm not convinced about the amount of entropy". The whole "third order time difference" thing would make sense if the time difference was some kind of smooth function - which it is at a macro level. But at a micro level, I could easily see the time difference having some very simple pattern - say that your cycle counter isn't really cycle-granular, and the load takes 5.33 "cycles" and you see a time difference pattern of (5, 5, 6, 5, 5, 6, ...). No real entropy at all there, it is 100% reliable. At a macro level, that's a very smooth curve, and you'd say "ok, time difference is 5. (repeating)". But that's not what the jitter entropy code does. It just does differences of differences. And that completely non-random pattern has a first-order difference of 0, 1, 1, 0, 1, 1.. and a second order of 1, 0, 1, 1, 0, and so on forever. So the "jitter entropy" logic will assign that completely repeatable thing entropy, because the delta difference doesn't ever go away. Maybe I misread it. You didn't. Let me generalize and rephrase the part of the concern that I agree with, in my own words: The same code is used in cryptoapi rng, and also a userspace version exists. These two have been tested by the author via the "dieharder" tool (see the message for commit d9d67c87), so we know that on his machine it actually produces good-quality random bits. However, the in-kernel self-test is much, much weaker, and would not catch the situation when someone's machine is deterministic in a way that you describe, or something similar. A constructive suggestion here would be to put the first few thousands (ok, a completely made up number) raw timing intervals through a "gzip compression test" in addition to the third derivative test, just based on what we already have in the kernel. -- Alexander E. Patrakov smime.p7s Description: Криптографическая подпись S/MIME
Re: [PATCH] base: soc: Export soc_device_to_device API
On 2019-09-19 15:45, Greg KH wrote:
On Thu, Sep 19, 2019 at 03:40:17PM -0700, Bjorn Andersson wrote:
On Thu 19 Sep 15:25 PDT 2019, Greg KH wrote:
> On Thu, Sep 19, 2019 at 03:14:56PM -0700, Bjorn Andersson wrote:
> > On Thu 19 Sep 14:58 PDT 2019, Greg KH wrote:
> >
> > > On Thu, Sep 19, 2019 at 02:53:00PM -0700, Bjorn Andersson wrote:
> > > > On Thu 19 Sep 14:32 PDT 2019, Greg KH wrote:
> > > >
> > > > > On Thu, Sep 19, 2019 at 02:13:44PM -0700, Murali Nalajala wrote:
> > > > > > If the soc drivers want to add custom sysfs entries it needs to
> > > > > > access "dev" field in "struct soc_device". This can be achieved
> > > > > > by "soc_device_to_device" API. Soc drivers which are built as a
> > > > > > module they need above API to be exported. Otherwise one can
> > > > > > observe compilation issues.
> > > > > >
> > > > > > Signed-off-by: Murali Nalajala
> > > > > > ---
> > > > > > drivers/base/soc.c | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/base/soc.c b/drivers/base/soc.c
> > > > > > index 7c0c5ca..4ad52f6 100644
> > > > > > --- a/drivers/base/soc.c
> > > > > > +++ b/drivers/base/soc.c
> > > > > > @@ -41,6 +41,7 @@ struct device *soc_device_to_device(struct
soc_device *soc_dev)
> > > > > > {
> > > > > > return _dev->dev;
> > > > > > }
> > > > > > +EXPORT_SYMBOL_GPL(soc_device_to_device);
> > > > > >
> > > > > > static umode_t soc_attribute_mode(struct kobject *kobj,
> > > > > > struct attribute *attr,
> > > > >
> > > > > What in-kernel driver needs this?
> > > > >
> > > >
> > > > Half of the drivers interacting with the soc driver calls this API,
> > > > several of these I see no reason for being builtin (e.g.
> > > > ux500 andversatile). So I think this patch makes sense to allow us to
> > > > build these as modules.
> > > >
> > > > > Is linux-next breaking without this?
> > > > >
> > > >
> > > > No, we postponed the addition of any sysfs attributes in the Qualcomm
> > > > socinfo driver.
> > > >
> > > > > We don't export things unless we have a user of the export.
> > > > >
> > > > > Also, adding "custom" sysfs attributes is almost always not the
correct
> > > > > thing to do at all. The driver should be doing it, by setting up the
> > > > > attribute group properly so that the driver core can do it
automatically
> > > > > for it.
> > > > >
> > > > > No driver should be doing individual add/remove of sysfs files. If it
> > > > > does so, it is almost guaranteed to be doing it incorrectly and racing
> > > > > userspace.
> > > > >
> > > >
> > > > The problem here is that the attributes are expected to be attached to
> > > > the soc driver, which is separate from the platform-specific drivers. So
> > > > there's no way to do platform specific attributes the right way.
> > > >
> > > > > And yes, there's loads of in-kernel examples of doing this wrong, I've
> > > > > been working on fixing that up, look at the patches now in Linus's
tree
> > > > > for platform and USB drivers that do this as examples of how to do it
> > > > > right.
> > > > >
> > > >
> > > > Agreed, this patch should not be used as an approval for any crazy
> > > > attributes; but it's necessary in order to extend the soc device's
> > > > attributes, per the current design.
> > >
> > > Wait, no, let's not let the "current design" remain if it is broken!
> > >
> > > Why can't the soc driver handle the attributes properly so that the
> > > individual driver doesn't have to do the create/remove?
> > >
> >
> > The custom attributes that these drivers want to add to the common ones
> > are known in advance, so I presume we could have them passed into
> > soc_device_register() and registered together with the common
> > attributes...
> >
> > It sounds like it's worth a prototype.
>
> Do you have an in-kernel example I can look at to get an idea of what is
> needed here?
>
realview_soc_probe(), in drivers/soc/versatile/soc-realview.c,
implements the current mechanism of acquiring the soc's struct device
and then issuing a few device_create_file calls on that.
That looks to be a trivial driver to fix up. Look at 6d03c140db2e
("USB: phy: fsl-usb: convert platform driver to use dev_groups") as an
example of how to do this.
Also gotta love the total lack of error checking when calling
device_create_file() in that driver :(
thanks,
greg k-h
You can see example here
https://android.googlesource.com/kernel/msm/+/android-7.1.0_r0.2/drivers/soc/qcom/socinfo.c#1356
I want to add the custom entries to "soc" device path. This can be
achieved if i go with "dev_groups"?
sys/devices/soc0 # ls -l
total 0
-r--r--r--1 root 0 4096 Jan 1 00:01 family
-r--r--r--1 root 0 4096 Jan 1 00:01 machine
drwxr-xr-x2 root 00 Jan 1 00:01 power
-r--r--r--1 root 0 4096 Jan 1 00:01 revision
-r--r--r--1 root 0 4096 Jan 1 00:01 serial_number
lrwxrwxrwx1 root 0
Re: [git pull] drm tree for 5.4-rc1
On Thu, Sep 19, 2019 at 12:09 PM Dave Airlie wrote:
>
> There are a few merge conflicts across the board, we have a shared
> rerere cache which meant I hadn't noticed them until I avoided the
> cache.
> https://cgit.freedesktop.org/drm/drm/log/?h=drm-5.4-merge
> contains what we've done, none of them are too crazy.
Hmm. My merge isn't identical to that. It's close though. Different
order for one #define which might be just from you and me merging
different directions.
But I also ended up removing the .gem_prime_export initialization to
drm_gem_prime_export, because it's the default if none exists. That's
the left-over from
3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
after the import stayed around because it got turned into an actually
non-default one.
I think that both of our merges are right - equivalent but just
slightly different.
But the reason I'm pointing this out is that I also get the feeling
that if it needs that dev->dev_private difference from the default
function in prime_import(), wouldn't it need the same for prime_export
too?
I don't know the code, and I don't know the hardware, but just from a
"pattern matching" angle I just wanted to check whether maybe there's
need for a mtk_drm_gem_prime_export() wrapper that does that same
thing with
struct mtk_drm_private *private = dev->dev_private;
.. use private->dev instead of dev->dev ..
So I'm just asking that somebody that knows that drm/mtk code should
double-check that oddity.
Thanks,
Linus
Re: [RFC] mm: Proactive compaction
On Tue, 2019-08-20 at 10:46 +0200, Vlastimil Babka wrote:
> > This patch is largely based on ideas from Michal Hocko posted here:
> > https://lore.kernel.org/linux-mm/20161230131412.gi13...@dhcp22.suse.cz/
> >
> > Testing done (on x86):
> > - Set /sys/kernel/mm/compaction/order-9/extfrag_{low,high} = {25, 30}
> > respectively.
> > - Use a test program to fragment memory: the program allocates all
> > memory
> > and then for each 2M aligned section, frees 3/4 of base pages using
> > munmap.
> > - kcompactd0 detects fragmentation for order-9 > extfrag_high and starts
> > compaction till extfrag < extfrag_low for order-9.
> >
> > The patch has plenty of rough edges but posting it early to see if I'm
> > going in the right direction and to get some early feedback.
>
> That's a lot of control knobs - how is an admin supposed to tune them to
> their
> needs?
Yes, it's difficult for an admin to get so many tunable right unless
targeting a very specific workload.
How about a simpler solution where we exposed just one tunable per-node:
/sys/.../node-x/compaction_effort
which accepts [0, 100]
This parallels /proc/sys/vm/swappiness but for compaction. With this
single number, we can estimate per-order [low, high] watermarks for external
fragmentation like this:
- For now, map this range to [low, medium, high] which correponds to specific
low, high thresholds for extfrag.
- Apply more relaxed thresholds for higher-order than for lower orders.
With this single tunable we remove the burden of setting per-order explicit
[low, high] thresholds and it should be easier to experiment with.
-Nitin
[for-next][PATCH 8/8] selftests/ftrace: Update kprobe event error testcase
From: Masami Hiramatsu Update kprobe event error testcase to test if it correctly finds the exact same probe event. Link: http://lkml.kernel.org/r/156879695513.31056.1580235733738840126.stgit@devnote2 Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) --- .../selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc index 39ef7ac1f51c..8a4025e912cb 100644 --- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc +++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc @@ -95,6 +95,7 @@ echo 'p:kprobes/testevent _do_fork abcd=\1' > kprobe_events check_error 'p:kprobes/testevent _do_fork ^bcd=\1' # DIFF_ARG_TYPE check_error 'p:kprobes/testevent _do_fork ^abcd=\1:u8' # DIFF_ARG_TYPE check_error 'p:kprobes/testevent _do_fork ^abcd=\"foo"'# DIFF_ARG_TYPE +check_error '^p:kprobes/testevent _do_fork'# SAME_PROBE fi exit 0 -- 2.20.1
[for-next][PATCH 0/8] tracing: Final updates before sending to Linus
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git for-next Head SHA1: b78b94b82122208902c0f83805e614e1239f9893 Andy Shevchenko (1): tracing: Be more clever when dumping hex in __print_hex() Changbin Du (1): ftrace: Simplify ftrace hash lookup code in clear_func_from_hash() Masami Hiramatsu (4): tracing/kprobe: Fix NULL pointer access in trace_porbe_unlink() tracing/probe: Fix to allow user to enable events on unloaded modules tracing/probe: Reject exactly same probe event selftests/ftrace: Update kprobe event error testcase Steven Rostedt (VMware) (1): selftests/ftrace: Select an existing function in kprobe_eventname test Tom Zanussi (1): tracing: Make sure variable reference alias has correct var_ref_idx kernel/trace/ftrace.c | 6 +- kernel/trace/trace_events_hist.c | 2 + kernel/trace/trace_kprobe.c| 69 +++--- kernel/trace/trace_output.c| 6 +- kernel/trace/trace_probe.c | 11 ++-- kernel/trace/trace_probe.h | 3 +- kernel/trace/trace_uprobe.c| 52 +--- .../ftrace/test.d/kprobe/kprobe_eventname.tc | 16 - .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 1 + 9 files changed, 123 insertions(+), 43 deletions(-)
[for-next][PATCH 6/8] tracing/probe: Fix to allow user to enable events on unloaded modules
From: Masami Hiramatsu
Fix to allow user to enable probe events on unloaded modules.
This operations was allowed before commit 60d53e2c3b75 ("tracing/probe:
Split trace_event related data from trace_probe"), because if users
need to probe module init functions, they have to enable those probe
events before loading module.
Link:
http://lkml.kernel.org/r/156879693733.31056.9331322616994665167.stgit@devnote2
Cc: sta...@vger.kernel.org
Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from
trace_probe")
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_kprobe.c | 17 +
1 file changed, 5 insertions(+), 12 deletions(-)
diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
index 7579c53bb053..0ba3239c0270 100644
--- a/kernel/trace/trace_kprobe.c
+++ b/kernel/trace/trace_kprobe.c
@@ -371,31 +371,24 @@ static int enable_trace_kprobe(struct trace_event_call
*call,
if (enabled)
return 0;
- enabled = false;
list_for_each_entry(pos, trace_probe_probe_list(tp), list) {
tk = container_of(pos, struct trace_kprobe, tp);
if (trace_kprobe_has_gone(tk))
continue;
ret = __enable_trace_kprobe(tk);
- if (ret) {
- if (enabled) {
- __disable_trace_kprobe(tp);
- enabled = false;
- }
+ if (ret)
break;
- }
enabled = true;
}
- if (!enabled) {
- /* No probe is enabled. Roll back */
+ if (ret) {
+ /* Failed to enable one of them. Roll back all */
+ if (enabled)
+ __disable_trace_kprobe(tp);
if (file)
trace_probe_remove_file(tp, file);
else
trace_probe_clear_flag(tp, TP_FLAG_PROFILE);
- if (!ret)
- /* Since all probes are gone, this is not available */
- ret = -EADDRNOTAVAIL;
}
return ret;
--
2.20.1
[for-next][PATCH 5/8] selftests/ftrace: Select an existing function in kprobe_eventname test
From: "Steven Rostedt (VMware)"
Running the ftrace selftests on the latest kernel caused the
kprobe_eventname test to fail. It was due to the test that searches for
a function with at "dot" in the name and adding a probe to that.
Unfortunately, for this test, it picked:
optimize_nops.isra.2.cold.4
Which happens to be marked as "__init", which means it no longer exists
in the kernel! (kallsyms keeps those function names around for tracing
purposes)
As only functions that still exist are in the
available_filter_functions file, as they are removed when the functions
are freed at boot or module exit, have the test search for a function
with ".isra." in the name as well as being in the
available_filter_functions (if the file exists).
Link: http://lkml.kernel.org/r/20190322150923.1b58e...@gandalf.local.home
Acked-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
.../ftrace/test.d/kprobe/kprobe_eventname.tc | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
index 3fb70e01b1fe..3ff236719b6e 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_eventname.tc
@@ -24,7 +24,21 @@ test -d events/kprobes2/event2 || exit_failure
:;: "Add an event on dot function without name" ;:
-FUNC=`grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 | cut -f 3
-d " "`
+find_dot_func() {
+ if [ ! -f available_filter_functions ]; then
+ grep -m 10 " [tT] .*\.isra\..*$" /proc/kallsyms | tail -n 1 |
cut -f 3 -d " "
+ return;
+ fi
+
+ grep " [tT] .*\.isra\..*" /proc/kallsyms | cut -f 3 -d " " | while read
f; do
+ if grep -s $f available_filter_functions; then
+ echo $f
+ break
+ fi
+ done
+}
+
+FUNC=`find_dot_func | tail -n 1`
[ "x" != "x$FUNC" ] || exit_unresolved
echo "p $FUNC" > kprobe_events
EVENT=`grep $FUNC kprobe_events | cut -f 1 -d " " | cut -f 2 -d:`
--
2.20.1
[for-next][PATCH 4/8] tracing/kprobe: Fix NULL pointer access in trace_porbe_unlink()
From: Masami Hiramatsu
Fix NULL pointer access in trace_probe_unlink() by initializing
trace_probe.list correctly in trace_probe_init().
In the error case of trace_probe_init(), it can call trace_probe_unlink()
before initializing trace_probe.list member. This causes NULL pointer
dereference at list_del_init() in trace_probe_unlink().
Syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8633 Comm: syz-executor797 Not tainted 5.3.0-rc8-next-20190915
#0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__list_del_entry_valid+0x85/0xf5 lib/list_debug.c:51
Code: 0f 84 e1 00 00 00 48 b8 22 01 00 00 00 00 ad de 49 39 c4 0f 84 e2 00
00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 75
53 49 8b 14 24 4c 39 f2 0f 85 99 00 00 00 49 8d 7d
RSP: 0018:888090a7f9d8 EFLAGS: 00010246
RAX: dc00 RBX: 88809b6f90c0 RCX: 817c0ca9
RDX: RSI: 817c0a73 RDI: 88809b6f90c8
RBP: 888090a7f9f0 R08: 88809a04e600 R09: ed1015d26aed
R10: ed1015d26aec R11: 8880ae935763 R12:
R13: R14: 88809b6f90c0 R15: 88809b6f90d0
FS: 56f99880() GS:8880ae90() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 006cc090 CR3: 962b2000 CR4: 001406e0
DR0: DR1: DR2:
DR3: DR6: fffe0ff0 DR7: 0400
Call Trace:
__list_del_entry include/linux/list.h:131 [inline]
list_del_init include/linux/list.h:190 [inline]
trace_probe_unlink+0x1f/0x200 kernel/trace/trace_probe.c:959
trace_probe_cleanup+0xd3/0x110 kernel/trace/trace_probe.c:973
trace_probe_init+0x3f2/0x510 kernel/trace/trace_probe.c:1011
alloc_trace_uprobe+0x5e/0x250 kernel/trace/trace_uprobe.c:353
create_local_trace_uprobe+0x109/0x4a0 kernel/trace/trace_uprobe.c:1508
perf_uprobe_init+0x131/0x210 kernel/trace/trace_event_perf.c:314
perf_uprobe_event_init+0x106/0x1a0 kernel/events/core.c:8898
perf_try_init_event+0x135/0x590 kernel/events/core.c:10184
perf_init_event kernel/events/core.c:10228 [inline]
perf_event_alloc.part.0+0x1b89/0x33d0 kernel/events/core.c:10505
perf_event_alloc kernel/events/core.c:10887 [inline]
__do_sys_perf_event_open+0xa2d/0x2d00 kernel/events/core.c:10989
__se_sys_perf_event_open kernel/events/core.c:10871 [inline]
__x64_sys_perf_event_open+0xbe/0x150 kernel/events/core.c:10871
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Link:
http://lkml.kernel.org/r/156869709721.22406.5153754822203046939.stgit@devnote2
Reported-by: syzbot+2f807f4d3a2a4e87f...@syzkaller.appspotmail.com
Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support")
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_probe.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index 1e67fef06e53..baf58a3612c0 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -986,6 +986,12 @@ int trace_probe_init(struct trace_probe *tp, const char
*event,
if (!tp->event)
return -ENOMEM;
+ INIT_LIST_HEAD(>event->files);
+ INIT_LIST_HEAD(>event->class.fields);
+ INIT_LIST_HEAD(>event->probes);
+ INIT_LIST_HEAD(>list);
+ list_add(>event->probes, >list);
+
call = trace_probe_event_call(tp);
call->class = >event->class;
call->name = kstrdup(event, GFP_KERNEL);
@@ -999,11 +1005,6 @@ int trace_probe_init(struct trace_probe *tp, const char
*event,
ret = -ENOMEM;
goto error;
}
- INIT_LIST_HEAD(>event->files);
- INIT_LIST_HEAD(>event->class.fields);
- INIT_LIST_HEAD(>event->probes);
- INIT_LIST_HEAD(>list);
- list_add(>event->probes, >list);
return 0;
--
2.20.1
