Re: [PATCH v3 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions

[Neil Armstrong]

On 17/01/2018 21:14, Jernej Skrabec wrote:
> Parts of PHY code could be useful also for custom PHYs. For example,
> Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
> with few additional memory mapped registers, so most of the Synopsys PHY
> related code could be reused.
> 
> Functions exported here are actually not specific to Synopsys PHYs but
> to DWC HDMI controller PHY interface. This means that even if the PHY is
> completely custom, i.e. not designed by Synopsys, exported functions can
> be useful.
> 
> Reviewed-by: Laurent Pinchart 
> Signed-off-by: Jernej Skrabec 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 
> +--
>  drivers/gpu/drm/meson/meson_dw_hdmi.c |  8 +++---
>  include/drm/bridge/dw_hdmi.h  | 11 
>  3 files changed, 45 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> index 7ca14d7325b5..7d80f4b56683 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> @@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi 
> *hdmi, u8 enable)
>HDMI_PHY_CONF0_SVSRET_MASK);
>  }
>  
> -static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
>HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
>  
> -static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
> +void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
>  {
>   hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
>HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
>HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
>  
>  static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
>  {
> @@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct 
> dw_hdmi *hdmi, u8 enable)
>HDMI_PHY_CONF0_SELDIPIF_MASK);
>  }
>  
> +void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
> +{
> + /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> + hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> + hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
> +
> +void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
> +{
> + hdmi_phy_test_clear(hdmi, 1);
> + hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
> + hdmi_phy_test_clear(hdmi, 0);
> +}
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
> +
>  static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
>  {
>   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
> @@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
>   if (phy->has_svsret)
>   dw_hdmi_phy_enable_svsret(hdmi, 1);
>  
> - /* PHY reset. The reset signal is active high on Gen2 PHYs. */
> - hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
> - hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
> + dw_hdmi_phy_reset(hdmi);
>  
>   hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
>  
> - hdmi_phy_test_clear(hdmi, 1);
> - hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
> - HDMI_PHY_I2CM_SLAVE_ADDR);
> - hdmi_phy_test_clear(hdmi, 0);
> + dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
>  
>   /* Write to the PHY as configured by the platform */
>   if (pdata->configure_phy)
> @@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi, 
> void *data)
>   dw_hdmi_phy_power_off(hdmi);
>  }
>  
> -static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> -   void *data)
> +enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
> +void *data)
>  {
>   return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
>   connector_status_connected : connector_status_disconnected;
>  }
> +EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
>  
> -static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> -bool force, bool disabled, bool rxsense)
> +void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
> + bool force, bool disabled, bool rxsense)
>  {
>   u8 old_mask = hdmi->phy_mask;
>  
> @@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi 
> *hdmi, void *data,
>   if (old_mask != hdmi->phy_mask)
>   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
>  }
> 

[PATCH] can: m_can: mark runtime-PM handlers as __maybe_unused

[Arnd Bergmann]

Building without CONFIG_PM results in a harmless warning:

drivers/net/can/m_can/m_can.c:1763:12: error: 'm_can_runtime_resume' defined 
but not used [-Werror=unused-function]
drivers/net/can/m_can/m_can.c:1752:12: error: 'm_can_runtime_suspend' defined 
but not used [-Werror=unused-function]

Marking the functions as __maybe_unused lets the compiler
silently drop them instead.

Fixes: cdf8259d6573 ("can: m_can: Add PM Support")
Signed-off-by: Arnd Bergmann 
---
 drivers/net/can/m_can/m_can.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/can/m_can/m_can.c b/drivers/net/can/m_can/m_can.c
index 49ed8737871f..2594f7779c6f 100644
--- a/drivers/net/can/m_can/m_can.c
+++ b/drivers/net/can/m_can/m_can.c
@@ -1749,7 +1749,7 @@ static int m_can_plat_remove(struct platform_device *pdev)
return 0;
 }
 
-static int m_can_runtime_suspend(struct device *dev)
+static int __maybe_unused m_can_runtime_suspend(struct device *dev)
 {
struct net_device *ndev = dev_get_drvdata(dev);
struct m_can_priv *priv = netdev_priv(ndev);
@@ -1760,7 +1760,7 @@ static int m_can_runtime_suspend(struct device *dev)
return 0;
 }
 
-static int m_can_runtime_resume(struct device *dev)
+static int __maybe_unused m_can_runtime_resume(struct device *dev)
 {
struct net_device *ndev = dev_get_drvdata(dev);
struct m_can_priv *priv = netdev_priv(ndev);
-- 
2.9.0

Re: [net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Antoine Tenart]

Hi Marcin,

I tested the series on a MacchiatoBin to ensure the mvpp2 DT support was
still working. I was able to use all supported ports as before, and saw
no issue.

For all mvpp2 patches, you can add:

Tested-by: Antoine Tenart 

Thanks!
Antoine

On Thu, Jan 18, 2018 at 01:31:37PM +0100, Marcin Wojtas wrote:
> Hi,
> 
> I quickly resend the series, thanks to Antoine Tenart's remark,
> who spotted !CONFIG_ACPI compilation issue after introducing
> the new fwnode_irq_get() routine. Please see the details in the changelog
> below and the 3/7 commit log.
> 
> mvpp2 driver can work with the ACPI representation, as exposed
> on a public branch:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
> It was compiled together with the most recent Tianocore EDK2 revision.
> Please refer to the firmware build instruction on MacchiatoBin board:
> http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II
> 
> ACPI representation of PP2 controllers (withouth PHY support) can
> be viewed in the github:
> * MacchiatoBin:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201
> 
> * Armada 7040 DB:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131
> 
> I will appreciate any comments or remarks.
> 
> Best regards,
> Marcin
> 
> Changelog:
> v3 -> v4:
> * 3/7
> - add new macro (ACPI_HANDLE_FWNODE) and fix
>   compilation with !CONFIG_ACPI
> - extend commit log and mention usability of fwnode_irq_get
>   for the child nodes as well
> 
> v2 -> v3:
> * 1/7, 2/7
> - Add Rafael's Acked-by's
> * 3/7, 4/7
> - New patches
> * 6/7, 7/7
> - Update driver with new helper routines usage
> - Improve commit log.
> 
> v1 -> v2:
> * Remove MDIO patches
> * Use PP2 ports only with link interrupts
> * Release second region resources in mvpp2 driver (code moved from
>   mvmdio), as explained in details in 5/5 commit message.
> 
> Marcin Wojtas (7):
>   device property: Introduce fwnode_get_mac_address()
>   device property: Introduce fwnode_get_phy_mode()
>   device property: Introduce fwnode_irq_get()
>   device property: Allow iterating over available child fwnodes
>   net: mvpp2: simplify maintaining enabled ports' list
>   net: mvpp2: use device_*/fwnode_* APIs instead of of_*
>   net: mvpp2: enable ACPI support in the driver
> 
>  drivers/base/property.c  | 104 --
>  drivers/net/ethernet/marvell/mvpp2.c | 206 
>  include/linux/acpi.h |   3 +
>  include/linux/property.h |  11 ++
>  4 files changed, 232 insertions(+), 92 deletions(-)
> 
> -- 
> 2.7.4
> 

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH] [wireless-next] mt76: fix building without CONFIG_LEDS_CLASS

[Kalle Valo]

Arnd Bergmann  writes:

> When CONFIG_LEDS_CLASS is disabled, or it is a loadable module while
> mt76 is built-in, we run into a link error:
>
> drivers/net/wireless/mediatek/mt76/mac80211.o: In function 
> `mt76_register_device':
> mac80211.c:(.text+0xb78): relocation truncated to fit: R_AARCH64_CALL26 
> against undefined symbol `devm_of_led_classdev_register'
>
> We don't really need a hard dependency here as the driver can presumably
> work just fine without LEDs, so this follows the iwlwifi example and
> adds a separate Kconfig option for the LED support, this will be available
> whenever it will link, and otherwise the respective code gets left out from
> the driver object.
>
> Fixes: 17f1de56df05 ("mt76: add common code shared between multiple chipsets")
> Signed-off-by: Arnd Bergmann 

I'm planning to queue this for 4.16.

-- 
Kalle Valo

Re: [PATCH v4 04/13] iommu/rockchip: Fix error handling in attach

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

From: Tomasz Figa 

Currently if the driver encounters an error while attaching device, it
will leave the IOMMU in an inconsistent state. Even though it shouldn't
really happen in reality, let's just add proper error path to keep
things consistent.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
Move irq request to probe(in patch[0])

  drivers/iommu/rockchip-iommu.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index b743d82e6fe1..37065a7127c9 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -824,7 +824,7 @@ static int rk_iommu_attach_device(struct iommu_domain 
*domain,
  
  	ret = rk_iommu_force_reset(iommu);

if (ret)
-   return ret;
+   goto err_disable_stall;
  
  	iommu->domain = domain;
  
@@ -837,7 +837,7 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
  
  	ret = rk_iommu_enable_paging(iommu);

if (ret)
-   return ret;
+   goto err_disable_stall;
  
  	spin_lock_irqsave(_domain->iommus_lock, flags);

list_add_tail(>node, _domain->iommus);
@@ -848,6 +848,11 @@ static int rk_iommu_attach_device(struct iommu_domain 
*domain,
rk_iommu_disable_stall(iommu);
  
  	return 0;


Nit: if you like, it looks reasonable to name the label 
"out_disable_stall" and remove these lines above here, to save the 
duplication between the error and success paths (since ret will already 
be 0 on the latter).


Either way,

Reviewed-by: Robin Murphy 


+
+err_disable_stall:
+   rk_iommu_disable_stall(iommu);
+
+   return ret;
  }
  
  static void rk_iommu_detach_device(struct iommu_domain *domain,

Re: [PATCH v5 3/5] misc serdev: Add w2sg0004 (gps receiver) power control driver

[H. Nikolaus Schaller]

Hi Johan,

> Am 18.01.2018 um 07:13 schrieb Johan Hovold :
> 
> Hacks are never good, but sometimes needed. But we should try to keep
> them contained in drivers rather than allow them to spread to core code,
> was what I was trying to say above.

Well, aren't we talking here about a well isolated driver? And not about
core code?

Core code already provides everything to build a driver for this chip
to make us happy with.

It is just not yet providing a generic gps interface API to make everybody
happy with.

>> That is what Andreas did remark as motivation: provide a solution
>> for *existing* user spaces.
> 
> I understand that this is what you want, but that in itself is not a
> sufficient reason to put something in the kernel.

Agreed, but it is a secondary (but still strong) motivation, not the primary 
one.

> 
 - can not guarantee (!) to power off the chip if the last user-space
 process using it is killed (which is essential for power-management of
 a handheld, battery operated device)
>>> 
>>> That depends on how you implement things (extending gpsd, wrapper
>>> script, pty daemon, ...).
>> 
>> No. You can of course cover all standard cases but there is one fundamental
>> issue which is IMHO a problem of any user-space implementation:
>> 
>>  How can you guarantee that the chip is powered off if no
>>  user-space process is using it or if the last process doing
>>  this is killed by *whatever* reason?
>> 
>> E.g. after a kill -9. Or if someone deinstalls gpsd or whatever and assumes
>> (and wants a guarantee) that GPS is now turned off and never turned on 
>> drawing
>> precious milliamps from the battery for no use.
> 
> Have something run at init to put the device in a low power state.

This does *not* solve the issue how to *guarantee* that it becomes
powered off if the number of user-space processes goes down to zero
*after* init.

Please consider that a portable device is rarely booted but might be
operated over several days with many suspend cycles. And people may
still expect that the power consumer "GPS" is turned off if their
personal user-space setup simply kills gpsd.

> 
>> As it is well known, a user-space process can't protect itself against kill 
>> -9.
>> Or has this recently been changed and I am not aware of?
>> 
>> This is the fundamental reason why we need a kernel driver to provide
>> reliable, repeatable and trustable power management of this chip.
>> 
>> It is equally fundamental as a hard disk should spin down after the last
>> file is closed. Even if this process ends by a kill -9.

Please advise how we should solve this fundamental problem in user-space.

>> 
>> This seems to contradict your argument that user-space can very easily
>> adapt to everything. If the latter were true there would be no need to
>> keep old interfaces supported for a long time.
> 
> You probably know that we try hard never to change an interface that
> would break user space, and that's why we need to get it right.

Yes, I know and agree that it is very important (and difficult to achieve).

But it seems that there are different opinions of what "right" is...

You seem to focus on the "right" API only (where we agree that the "right"
API does not exist and likely will never come or at least in the near future).

But for us the whole combination of kernel + user-space must behave "right"
(and use a function split that allows to optimally achieve this goal).

> 
>> So can you agree to that a battery powered portable device must have
>> reliable and trustable power management? And if it provable can't be
>> implemented in user-space (a single counter example suffices) it must
>> be a kernel driver?
> 
> Having a kernel driver would make things easier for user space, sure,
> but again, that's not a sufficient reason to merge just any kernel
> implementation.

It is not about "easier" for anyone. Neither for you nor for me. For us
it would be much easier not to have to run this never-ending discussion
over and over...

It is about making it technically fully "reliable". And not 99% as per
quick and dirty user-space hacks.

It is so easy to invent scenarios in user-space to make the device practically
unusable by unnoticed draining a full battery within less than a day when
not perfectly turning off the chip power.

So if a kernel driver can better protect users against this situation for
a portable device with this chip, why shouldn't it do with a handful LOC?
What requirement is more important than this?

BR and thanks,
Nikolaus

Re: [PATCH v2 0/2] arm64: Run enable method for errata work arounds on late CPUs

[Dave Martin]

On Thu, Jan 18, 2018 at 12:08:43PM +, Robin Murphy wrote:
> On 18/01/18 12:00, Robin Murphy wrote:
> [...]
> >>+struct enable_arg {
> >>+    int (*enable)(struct arm64_cpu_capabilities const *);
> >>+    struct arm64_cpu_capabilities const *cap;
> >>+};
> >>+
> >>+static int __enable_cpu_capability(void *arg)
> >>+{
> >>+    struct enable_arg const *e = arg;
> >>+
> >>+    return e->enable(e->cap);
> >>+}
> >
> >AFAICS, you shouldn't even need the intermediate struct - if you were
> >instead to call stop_machine(>enable, ...), the wrapper could be:
> >
> >  **fn = arg;
> > *fn(container_of(fn, struct arm64_cpu_capabilities, enable));
> >
> >(cheaty pseudocode because there's no way I'm going to write a
> >pointer-to-function-pointer type correctly in an email client...)
> >
> >That's certainly a fair bit simpler in terms of diffstat; whether it's
> >really as intuitive as I think it is is perhaps another matter, though.
> 
> Ah, right, but then you'd be back to casting away const, and at that point
> it makes no sense to do the container_of dance instead of just passing the
> struct pointer itself around...
> 
> I shall now excuse myself from this discussion, as I'm clearly not helping
> :)
> 
> Robin.

That's what I was about to say... but neat trick.

However, it does concentrate the type fudge in one place and keeps the
arm64_cpu_capabilities::enable() prototype correct, so it's still better
than the original.


Thinking about it, the following is probably clearer and no worse:

static int __enable_cpu_capability(void *arg)
{
struct arm64_cpu_capabilities const *cap = arg;

return cap->enable(cap);
}

...

stop_machine(__enable_cpu_capability, (void *)caps, cpu_online_mask);


In your version, the argument would be (void *)>enable, which is
really just a proxy for (void *)caps, unless I missed something.


What do you think Suzuki?  I can respin my patch if you fancy picking it
up.  Either way, it's not urgent.

Cheers
---Dave

[PATCH v3 10/14] ARM: dts: stm32: Enable SDIO controller on stm32429i-eval board

[patrice.chotard]

From: Patrice Chotard 

This patch adds SDIO related DT nodes for stm32429i-eval board.

Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ none


 arch/arm/boot/dts/stm32429i-eval.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/stm32429i-eval.dts 
b/arch/arm/boot/dts/stm32429i-eval.dts
index 1e3d4c6..6a5c701 100644
--- a/arch/arm/boot/dts/stm32429i-eval.dts
+++ b/arch/arm/boot/dts/stm32429i-eval.dts
@@ -144,6 +144,13 @@
};
};
};
+
+   mmc_vcard: mmc_vcard {
+   compatible = "regulator-fixed";
+   regulator-name = "mmc_vcard";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
 };
 
  {
@@ -254,6 +261,18 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_vcard>;
+   cd-gpios = < 15 GPIO_ACTIVE_HIGH>;
+   cd-inverted;
+   pinctrl-names = "default", "opendrain";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_od>;
+   bus-width = <4>;
+   max-frequency = <1250>;
+};
+
  {
status = "okay";
 
-- 
1.9.1

[PATCH v3 08/14] ARM: dts: stm32: Add pin map for SDIO controller on stm32f4

[patrice.chotard]

From: Andrea Merello 

This patch adds the pin configuration for SDIO controller on
stm32f4.

Signed-off-by: Andrea Merello 
Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ none


 arch/arm/boot/dts/stm32f4-pinctrl.dtsi | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi 
b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
index ae94d86..3520289 100644
--- a/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
+++ b/arch/arm/boot/dts/stm32f4-pinctrl.dtsi
@@ -338,6 +338,37 @@
slew-rate = <3>;
};
};
+
+   sdio_pins: sdio_pins@0 {
+   pins {
+   pinmux = , 
/* SDIO_D0 */
+, 
/* SDIO_D1 */
+, 
/* SDIO_D2 */
+, 
/* SDIO_D3 */
+, 
/* SDIO_CK */
+; 
/* SDIO_CMD */
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+   };
+
+   sdio_pins_od: sdio_pins_od@0 {
+   pins1 {
+   pinmux = , 
/* SDIO_D0 */
+, 
/* SDIO_D1 */
+, 
/* SDIO_D2 */
+, 
/* SDIO_D3 */
+; 
/* SDIO_CK */
+   drive-push-pull;
+   slew-rate = <2>;
+   };
+
+   pins2 {
+   pinmux = ; 
/* SDIO_CMD */
+   drive-open-drain;
+   slew-rate = <2>;
+   };
+   };
};
};
 };
-- 
1.9.1

[PATCH v3 07/14] ARM: dts: stm32: Add SDIO controller for stm32f429

[patrice.chotard]

From: Patrice Chotard 

stm32f429 embeds ARM_PL180 sdi IP, adds SDIO controller
node to allow MMC support.

Signed-off-by: Andrea Merello 
Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ none


 arch/arm/boot/dts/stm32f429.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index 10099df..ede77e0 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -511,6 +511,17 @@
};
};
 
+   sdio: sdio@40012c00 {
+   compatible = "arm,pl180", "arm,primecell";
+   arm,primecell-periphid = <0x00880180>;
+   reg = <0x40012c00 0x400>;
+   clocks = < 0 STM32F4_APB2_CLOCK(SDIO)>;
+   clock-names = "apb_pclk";
+   interrupts = <49>;
+   max-frequency = <4800>;
+   status = "disabled";
+   };
+
syscfg: system-config@40013800 {
compatible = "syscon";
reg = <0x40013800 0x400>;
-- 
1.9.1

[PATCH v3 05/14] mmc: mmci: Add STM32 variant

[patrice.chotard]

From: Patrice Chotard 

STM32F4 and STM32F7 MCUs has a SDIO controller that looks like
an ARM PL810.
This patch adds the STM32 variant so that mmci driver supports it.

Signed-off-by: Andrea Merello 
Signed-off-by: Patrice Chotard 
Reviewed-by: Linus Walleij 
---

v3: _ none

v2: _ Replace "pl180" by "PL180" in commit message

 drivers/mmc/host/mmci.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 9918a5f..30c93c9 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -244,6 +244,23 @@ struct variant_data {
.opendrain  = MCI_OD,
 };
 
+static struct variant_data variant_stm32 = {
+   .fifosize   = 32 * 4,
+   .fifohalfsize   = 8 * 4,
+   .clkreg = MCI_CLK_ENABLE,
+   .clkreg_enable  = MCI_ST_UX500_HWFCEN,
+   .clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
+   .clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE,
+   .datalength_bits= 24,
+   .datactrl_mask_sdio = MCI_DPSM_ST_SDIOEN,
+   .st_sdio= true,
+   .st_clkdiv  = true,
+   .pwrreg_powerup = MCI_PWR_ON,
+   .f_max  = 4800,
+   .pwrreg_clkgate = true,
+   .pwrreg_nopower = true,
+};
+
 static struct variant_data variant_qcom = {
.fifosize   = 16 * 4,
.fifohalfsize   = 8 * 4,
@@ -2021,6 +2038,11 @@ static int mmci_runtime_resume(struct device *dev)
.mask   = 0xf0ff,
.data   = _ux500v2,
},
+   {
+   .id = 0x00880180,
+   .mask   = 0x00ff,
+   .data   = _stm32,
+   },
/* Qualcomm variants */
{
.id = 0x00051180,
-- 
1.9.1

[PATCH 34/35] x86/kvm: Add IBPB support

[Peter Zijlstra]

From: Ashok Raj 

Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
barriers on switching between VMs to avoid inter VM specte-v2 attacks.

[peterz: rebase and changelog rewrite]

Cc: Asit Mallick 
Cc: Dave Hansen 
Cc: Arjan Van De Ven 
Cc: Tim Chen 
Cc: Linus Torvalds 
Cc: Andrea Arcangeli 
Cc: Andi Kleen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Andy Lutomirski 
Cc: Greg KH 
Cc: David Woodhouse 
Cc: Paolo Bonzini 
Signed-off-by: Ashok Raj 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kvm/svm.c |8 
 arch/x86/kvm/vmx.c |8 
 2 files changed, 16 insertions(+)

--- a/arch/x86/kvm/svm.c
+++ b/arch/x86/kvm/svm.c
@@ -252,6 +252,7 @@ static const struct svm_direct_access_ms
{ .index = MSR_SYSCALL_MASK,.always = true  },
 #endif
{ .index = MSR_IA32_SPEC_CTRL,  .always = true  },
+   { .index = MSR_IA32_PRED_CMD,   .always = true },
{ .index = MSR_IA32_LASTBRANCHFROMIP,   .always = false },
{ .index = MSR_IA32_LASTBRANCHTOIP, .always = false },
{ .index = MSR_IA32_LASTINTFROMIP,  .always = false },
@@ -532,6 +533,7 @@ struct svm_cpu_data {
struct kvm_ldttss_desc *tss_desc;
 
struct page *save_area;
+   struct vmcb *current_vmcb;
 };
 
 static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
@@ -1709,11 +1711,13 @@ static void svm_free_vcpu(struct kvm_vcp
__free_pages(virt_to_page(svm->nested.msrpm), MSRPM_ALLOC_ORDER);
kvm_vcpu_uninit(vcpu);
kmem_cache_free(kvm_vcpu_cache, svm);
+   indirect_branch_prediction_barrier();
 }
 
 static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
+   struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
int i;
 
if (unlikely(cpu != vcpu->cpu)) {
@@ -1742,6 +1746,10 @@ static void svm_vcpu_load(struct kvm_vcp
if (static_cpu_has(X86_FEATURE_RDTSCP))
wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
 
+   if (sd->current_vmcb != svm->vmcb) {
+   sd->current_vmcb = svm->vmcb;
+   indirect_branch_prediction_barrier();
+   }
avic_vcpu_load(vcpu, cpu);
 }
 
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -2280,6 +2280,7 @@ static void vmx_vcpu_load(struct kvm_vcp
if (per_cpu(current_vmcs, cpu) != vmx->loaded_vmcs->vmcs) {
per_cpu(current_vmcs, cpu) = vmx->loaded_vmcs->vmcs;
vmcs_load(vmx->loaded_vmcs->vmcs);
+   indirect_branch_prediction_barrier();
}
 
if (!already_loaded) {
@@ -3837,6 +3838,11 @@ static void free_loaded_vmcs(struct load
free_vmcs(loaded_vmcs->vmcs);
loaded_vmcs->vmcs = NULL;
WARN_ON(loaded_vmcs->shadow_vmcs != NULL);
+   /*
+* The VMCS could be recycled, causing a false negative in vmx_vcpu_load
+* block speculative execution.
+*/
+   indirect_branch_prediction_barrier();
 }
 
 static void free_kvm_area(void)
@@ -6804,6 +6810,8 @@ static __init int hardware_setup(void)
 */
if (boot_cpu_has(X86_FEATURE_SPEC_CTRL))
vmx_disable_intercept_for_msr(MSR_IA32_SPEC_CTRL, false);
+   if (boot_cpu_has(X86_FEATURE_IBPB))
+   vmx_disable_intercept_for_msr(MSR_IA32_PRED_CMD, false);
 
vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
vmx_disable_intercept_for_msr(MSR_GS_BASE, false);

[PATCH 15/35] objtool: More complex static jump implementation

[Peter Zijlstra]

When using something like:

  -#define sched_feat(x) (static_branch_##x(_feat_keys[__SCHED_FEAT_##x]))
  +#define sched_feat(x) (static_branch_##x(_feat_keys[__SCHED_FEAT_##x]) 
&& \
  + (arch_static_assert(), true))

we get an objtool assertion fail like:

kernel/sched/fair.o: warning: objtool: hrtick_update()+0xd: static assert FAIL

where:

1140 :
1140:   0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
1145:   c3  retq
1146:   48 8b b7 30 09 00 00mov0x930(%rdi),%rsi
114d:   8b 87 d8 09 00 00   mov0x9d8(%rdi),%eax
1153:   48 0f a3 05 00 00 00bt %rax,0x0(%rip)# 115b 

115a:   00
1157: R_X86_64_PC32 __cpu_active_mask-0x4

and:

RELOCATION RECORDS FOR [__jump_table]:
0150 R_X86_64_64   .text+0x1140
0158 R_X86_64_64   .text+0x1146

RELOCATION RECORDS FOR [.discard.jump_assert]:
0028 R_X86_64_64   .text+0x114d

IOW, GCC managed to place the assertion 1 instruction _after_ the
static jump target (it lifted a load over it).

So while the code generation is fine, the assertion gets placed wrong.
We can 'fix' this by not only considering the immediate static jump
locations but also all the unconditional code after it, terminating
the basic block on any unconditional instruction or branch entry
point.

Signed-off-by: Peter Zijlstra (Intel) 
---
 tools/objtool/check.c |   41 +
 tools/objtool/check.h |2 +-
 2 files changed, 42 insertions(+), 1 deletion(-)

--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -520,6 +520,8 @@ static int add_jump_destinations(struct
  dest_off);
return -1;
}
+
+   insn->jump_dest->branch_target = true;
}
 
return 0;
@@ -1197,6 +1199,41 @@ static int read_retpoline_hints(struct o
return 0;
 }
 
+static int grow_static_blocks(struct objtool_file *file)
+{
+   struct instruction *insn;
+   bool static_block = false;
+
+   for_each_insn(file, insn) {
+   if (!static_block && !insn->static_jump_dest)
+   continue;
+
+   if (insn->static_jump_dest) {
+   static_block = true;
+   continue;
+   }
+
+   if (insn->branch_target) {
+   static_block = false;
+   continue;
+   } else switch (insn->type) {
+   case INSN_JUMP_CONDITIONAL:
+   case INSN_JUMP_UNCONDITIONAL:
+   case INSN_JUMP_DYNAMIC:
+   case INSN_CALL:
+   case INSN_CALL_DYNAMIC:
+   case INSN_RETURN:
+   case INSN_BUG:
+   static_block = false;
+   continue;
+   }
+
+   insn->static_jump_dest = static_block;
+   }
+
+   return 0;
+}
+
 static int decode_sections(struct objtool_file *file)
 {
int ret;
@@ -1239,6 +1276,10 @@ static int decode_sections(struct objtoo
if (ret)
return ret;
 
+   ret = grow_static_blocks(file);
+   if (ret)
+   return ret;
+
return 0;
 }
 
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -45,7 +45,7 @@ struct instruction {
unsigned char type;
unsigned long immediate;
bool alt_group, visited, dead_end, ignore, hint, save, restore, 
ignore_alts;
-   bool static_jump_dest, retpoline_safe;
+   bool static_jump_dest, retpoline_safe, branch_target;
struct symbol *call_dest;
struct instruction *jump_dest;
struct list_head alts;

[PATCH 22/35] x86/cpufeatures: Detect Speculation control feature

[Peter Zijlstra]

From: Tim Chen 

CPUs can expose a MSR to control speculation. The initial function of this
MSR is to control Indirect Branch Speculation, which is required to
mitigate the Spectre_V2 attack on certain CPU generations.

If CPUID(7).RDX[26] is set then MSR_IA32_SPEC_CTRL (0x48) is available and
bit 0 of that MSR controls whether Indirect Branch Speculation is
restricted or not. The control bit is named IBRS (Indirect Branch
Restricted Speculation). The IBSR bit can be unconditionally set to 1
without clearing it before.

If IBRS is set, near returns and near indirect jumps/calls will not allow
their predicted target address to be controlled by code that executed in a
less privileged prediction mode before the IBRS mode was last written with
a value of 1 or on another logical processor so long as all Return Stack
Buffer (RSB) entries from the previous less privileged prediction mode are
overwritten.

Thus a near indirect jump/call/return may be affected by code in a less
privileged prediction mode that executed AFTER IBRS mode was last written
with a value of 1.

Code executed by a sibling logical processor cannot control indirect
jump/call/return predicted target when IBRS is set

IBRS is not required in order to isolate branch predictions for SMM or SGX
enclaves.

Enabling IBRS can cause a measurable and depending on the workload
significant CPU performance penalty.

[ tglx: Steam blastered changelog ]

Cc: Arjan Van De Ven 
Cc: Dave Hansen 
Cc: Linus Torvalds 
Cc: Andi Kleen 
Cc: Andrea Arcangeli 
Cc: David Woodhouse 
Cc: Andy Lutomirski 
Cc: Greg KH 
Signed-off-by: Tim Chen 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/cpufeatures.h |2 ++
 arch/x86/include/asm/msr-index.h   |4 
 arch/x86/kernel/cpu/scattered.c|1 +
 3 files changed, 7 insertions(+)

--- a/arch/x86/include/asm/cpufeatures.h
+++ b/arch/x86/include/asm/cpufeatures.h
@@ -211,6 +211,8 @@
 
 #define X86_FEATURE_MBA( 7*32+18) /* Memory Bandwidth 
Allocation */
 #define X86_FEATURE_RSB_CTXSW  ( 7*32+19) /* Fill RSB on context 
switches */
+#define X86_FEATURE_SPEC_CTRL  ( 7*32+20) /* Speculation Control */
+#define X86_FEATURE_IBRS   ( 7*32+21) /* Indirect Branch 
Restricted Speculation */
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -42,6 +42,10 @@
 #define MSR_PPIN_CTL   0x004e
 #define MSR_PPIN   0x004f
 
+#define MSR_IA32_SPEC_CTRL 0x0048
+#define SPEC_CTRL_DISABLE_IBRS (0 << 0)
+#define SPEC_CTRL_ENABLE_IBRS  (1 << 0)
+
 #define MSR_IA32_PERFCTR0  0x00c1
 #define MSR_IA32_PERFCTR1  0x00c2
 #define MSR_FSB_FREQ   0x00cd
--- a/arch/x86/kernel/cpu/scattered.c
+++ b/arch/x86/kernel/cpu/scattered.c
@@ -23,6 +23,7 @@ static const struct cpuid_bit cpuid_bits
{ X86_FEATURE_EPB,  CPUID_ECX,  3, 0x0006, 0 },
{ X86_FEATURE_AVX512_4VNNIW,CPUID_EDX,  2, 0x0007, 0 },
{ X86_FEATURE_AVX512_4FMAPS,CPUID_EDX,  3, 0x0007, 0 },
+   { X86_FEATURE_SPEC_CTRL,CPUID_EDX, 26, 0x0007, 0 },
{ X86_FEATURE_CAT_L3,   CPUID_EBX,  1, 0x0010, 0 },
{ X86_FEATURE_CAT_L2,   CPUID_EBX,  2, 0x0010, 0 },
{ X86_FEATURE_CDP_L3,   CPUID_ECX,  2, 0x0010, 1 },

Re: [PATCH v1 1/1] usb: xhci: do not create and register shared_hcd when USB3.0 is disabled

[Mathias Nyman]

On 18.01.2018 09:27, Tung Vuong Nguyen wrote:

On Tue, Jan 16, 2018 at 9:50 PM, Mathias Nyman
 wrote:


Hi, Sorry about the delay


On 04.01.2018 07:17, Thang Q. Nguyen wrote:


Hi,

On Sat, Dec 16, 2017 at 10:45 AM, Thang Q. Nguyen  wrote:


From: Tung Nguyen 

Currently, hcd->shared_hcd always creates and registers to the usb-core.
If, for some reasons, USB3 downstream port is disabled, no roothub port for
USB3.0 is found. This causes kernel to display an error:
hub 2-0:1.0: config failed, hub doesn't have any ports! (err -19)
This patch checks, creates and registers shared_hcd if USB3.0 downstream
port is available.

Signed-off-by: Tung Nguyen 
Signed-off-by: Thang Q. Nguyen 
---
   drivers/usb/host/xhci-mem.c  |  2 +-
   drivers/usb/host/xhci-plat.c | 26 +++--
   drivers/usb/host/xhci.c  | 54 

   3 files changed, 54 insertions(+), 28 deletions(-)

diff --git a/drivers/usb/host/xhci-mem.c b/drivers/usb/host/xhci-mem.c
index 554a8a5..157d1e7 100644
--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -1067,7 +1067,7 @@ static u32 xhci_find_real_port_number(struct xhci_hcd 
*xhci,
  struct usb_device *top_dev;
  struct usb_hcd *hcd;

-   if (udev->speed >= USB_SPEED_SUPER)
+   if (udev->speed >= USB_SPEED_SUPER && xhci->shared_hcd)
  hcd = xhci->shared_hcd;
  else
  hcd = xhci->main_hcd;
diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 6f03830..e812e3d 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -253,12 +253,6 @@ static int xhci_plat_probe(struct platform_device *pdev)

  xhci->clk = clk;
  xhci->main_hcd = hcd;
-   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
-   dev_name(>dev), hcd);
-   if (!xhci->shared_hcd) {
-   ret = -ENOMEM;
-   goto disable_clk;
-   }

  if (device_property_read_bool(sysdev, "usb2-lpm-disable"))
  xhci->quirks |= XHCI_HW_LPM_DISABLE;
@@ -290,12 +284,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
  if (ret)
  goto disable_usb_phy;

-   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
-   xhci->shared_hcd->can_do_streams = 1;
-
-   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
-   if (ret)
-   goto dealloc_usb2_hcd;
+   if (xhci->num_usb3_ports > 0) {
+   xhci->shared_hcd = __usb_create_hcd(driver, sysdev, >dev,
+   dev_name(>dev), hcd);
+   if (!xhci->shared_hcd) {
+   ret = -ENOMEM;
+   goto disable_clk;
+   }
+   if (HCC_MAX_PSA(xhci->hcc_params) >= 4)
+   xhci->shared_hcd->can_do_streams = 1;
+
+   ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
+   if (ret)
+   goto dealloc_usb2_hcd;
+   }

  device_enable_async_suspend(>dev);
  pm_runtime_put_noidle(>dev);
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 05104bd..4824bf6 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -417,12 +417,14 @@ static void compliance_mode_recovery(struct timer_list *t)
  i + 1);
  xhci_dbg_trace(xhci, trace_xhci_dbg_quirks,
  "Attempting compliance mode 
recovery");
-   hcd = xhci->shared_hcd;
+   if (xhci->shared_hcd) {
+   hcd = xhci->shared_hcd;

-   if (hcd->state == HC_STATE_SUSPENDED)
-   usb_hcd_resume_root_hub(hcd);
+   if (hcd->state == HC_STATE_SUSPENDED)
+   usb_hcd_resume_root_hub(hcd);

-   usb_hcd_poll_rh_status(hcd);
+   usb_hcd_poll_rh_status(hcd);
+   }
  }
  }

@@ -611,6 +613,18 @@ int xhci_run(struct usb_hcd *hcd)
  if (ret)
  xhci_free_command(xhci, command);
  }
+   /*
+* Execute xhci_start() in case xhci->shared_hcd is not registered.
+* If the xhci->shared_hcd doesn't exist, no one triggers to start
+* the xhci which should be done before exitting run function
+*/
+   if (!xhci->shared_hcd) {
+   if (xhci_start(xhci)) {



This probably won't work as primary hcd was added before shared_hcd was created.
usb_add_hcd(hcd) calls xhci_run() before xhci->shared_hcd exists, so this will
cause the xHC to start before the shared_hcd is created or setup.

-Mathias


Hi Mathias
I 

[PATCH 21/35] x86: Remove FAST_FEATURE_TESTS

[Peter Zijlstra]

Since we want to rely on static branches to avoid speculation, remove
any possible fallback code for static_cpu_has.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/Kconfig  |   11 ---
 arch/x86/include/asm/cpufeature.h |8 
 2 files changed, 19 deletions(-)

--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -389,17 +389,6 @@ config X86_FEATURE_NAMES
 
  If in doubt, say Y.
 
-config X86_FAST_FEATURE_TESTS
-   bool "Fast CPU feature tests" if EMBEDDED
-   default y
-   ---help---
- Some fast-paths in the kernel depend on the capabilities of the CPU.
- Say Y here for the kernel to patch in the appropriate code at runtime
- based on the capabilities of the CPU. The infrastructure for patching
- code at runtime takes up some additional space; space-constrained
- embedded systems may wish to say N here to produce smaller, slightly
- slower code.
-
 config X86_X2APIC
bool "Support x2apic"
depends on X86_LOCAL_APIC && X86_64 && (IRQ_REMAP || HYPERVISOR_GUEST)
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -137,7 +137,6 @@ extern void clear_cpu_cap(struct cpuinfo
 
 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
 
-#if defined(CC_HAVE_ASM_GOTO) && defined(CONFIG_X86_FAST_FEATURE_TESTS)
 /*
  * Static testing of CPU features.  Used the same as boot_cpu_has().
  * These will statically patch the target code for additional
@@ -196,13 +195,6 @@ static __always_inline __pure bool _stat
boot_cpu_has(bit) : \
_static_cpu_has(bit)\
 )
-#else
-/*
- * Fall back to dynamic for gcc versions which don't support asm goto. Should 
be
- * a minority now anyway.
- */
-#define static_cpu_has(bit)boot_cpu_has(bit)
-#endif
 
 #define cpu_has_bug(c, bit)cpu_has(c, (bit))
 #define set_cpu_bug(c, bit)set_cpu_cap(c, (bit))

[PATCH 10/35] x86/jump_label: Implement arch_static_assert()

[Peter Zijlstra]

Implement the static (branch) assertion. It simply emits the address
of the next instruction into a special section which objtool will read
and validate against either __jump_table or .altinstructions.

Use like:

if (static_branch_likely(_key)) {
arch_static_assert();
/* do stuff */
}

Or

if (static_cpu_has(_feat)) {
arch_static_assert();
/* do stuff */
}

Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Josh Poimboeuf 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/jump_label.h |   23 +++
 1 file changed, 23 insertions(+)

--- a/arch/x86/include/asm/jump_label.h
+++ b/arch/x86/include/asm/jump_label.h
@@ -62,6 +62,29 @@ static __always_inline bool arch_static_
return true;
 }
 
+/*
+ * Annotation for objtool; asserts that the previous instruction is the
+ * jump_label patch site. Or rather, that the next instruction is a static
+ * branch target.
+ *
+ * Use like:
+ *
+ * if (static_branch_likely(key)) {
+ * arch_static_assert();
+ * do_code();
+ * }
+ *
+ * Also works with static_cpu_has().
+ */
+static __always_inline void arch_static_assert(void)
+{
+   asm volatile ("1:\n\t"
+ ".pushsection .discard.jump_assert \n\t"
+ _ASM_ALIGN  "\n\t"
+ _ASM_PTR "1b \n\t"
+ ".popsection \n\t");
+}
+
 #ifdef CONFIG_X86_64
 typedef u64 jump_label_t;
 #else

[PATCH 23/35] x86/speculation: Add basic speculation control code

[Peter Zijlstra]

From: Thomas Gleixner 

Add the minimal infrastructure to control the speculation control feature.

 - Integrate it into the spectre_v2 coammand line parser and the mitigation
   selector function. The conditional selector function is a placeholder
   right now, which needs to be expanded with CPU specific decision
   functions.

 - Provide a static key for the actual code control.

 - Provide a init function which is called after jump label patching is
   functional.

 - Provide an interface for the late micro code loader to allow late
   discovery of the IBRS support. Not yet functional.

[peterz: fixed Makefile]

Signed-off-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
---
 Documentation/admin-guide/kernel-parameters.txt |1 
 arch/x86/include/asm/nospec-branch.h|5 +++
 arch/x86/kernel/cpu/Makefile|1 
 arch/x86/kernel/cpu/bugs.c  |   26 +-
 arch/x86/kernel/cpu/specctrl.c  |   33 
 5 files changed, 64 insertions(+), 2 deletions(-)

--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3932,6 +3932,7 @@
retpoline - replace indirect branches
retpoline,generic - google's original retpoline
retpoline,amd - AMD-specific minimal thunk
+   ibrs  - Intel: Indirect Branch Restricted 
Speculation
 
Not specifying this option is equivalent to
spectre_v2=auto.
--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -214,5 +214,10 @@ static inline void vmexit_fill_RSB(void)
  : "r" (loops) : "memory" );
 #endif
 }
+
+bool specctrl_force_enable_ibrs(void);
+bool specctrl_cond_enable_ibrs(bool full_retpoline);
+bool is_skylake_era(void);
+
 #endif /* __ASSEMBLY__ */
 #endif /* __NOSPEC_BRANCH_H__ */
--- a/arch/x86/kernel/cpu/Makefile
+++ b/arch/x86/kernel/cpu/Makefile
@@ -24,6 +24,7 @@ obj-y += match.o
 obj-y  += bugs.o
 obj-$(CONFIG_CPU_FREQ) += aperfmperf.o
 obj-y  += cpuid-deps.o
+obj-y  += specctrl.o
 
 obj-$(CONFIG_PROC_FS)  += proc.o
 obj-$(CONFIG_X86_FEATURE_NAMES) += capflags.o powerflags.o
--- a/arch/x86/kernel/cpu/bugs.c
+++ b/arch/x86/kernel/cpu/bugs.c
@@ -79,6 +79,7 @@ enum spectre_v2_mitigation_cmd {
SPECTRE_V2_CMD_RETPOLINE,
SPECTRE_V2_CMD_RETPOLINE_GENERIC,
SPECTRE_V2_CMD_RETPOLINE_AMD,
+   SPECTRE_V2_CMD_IBRS,
 };
 
 static const char *spectre_v2_strings[] = {
@@ -87,6 +88,7 @@ static const char *spectre_v2_strings[]
[SPECTRE_V2_RETPOLINE_MINIMAL_AMD]  = "Vulnerable: Minimal AMD ASM 
retpoline",
[SPECTRE_V2_RETPOLINE_GENERIC]  = "Mitigation: Full generic 
retpoline",
[SPECTRE_V2_RETPOLINE_AMD]  = "Mitigation: Full AMD 
retpoline",
+   [SPECTRE_V2_IBRS]   = "Mitigation: Indirect Branch 
Restricted Speculation",
 };
 
 #undef pr_fmt
@@ -144,6 +146,8 @@ static enum spectre_v2_mitigation_cmd __
} else if (match_option(arg, ret, "retpoline,generic")) {
spec2_print_if_insecure("generic retpoline selected on 
command line.");
return SPECTRE_V2_CMD_RETPOLINE_GENERIC;
+   } else if (match_option(arg, ret, "ibrs")) {
+   return SPECTRE_V2_CMD_IBRS;
} else if (match_option(arg, ret, "auto")) {
return SPECTRE_V2_CMD_AUTO;
}
@@ -156,8 +160,8 @@ static enum spectre_v2_mitigation_cmd __
return SPECTRE_V2_CMD_NONE;
 }
 
-/* Check for Skylake-like CPUs (for RSB handling) */
-static bool __init is_skylake_era(void)
+/* Check for Skylake-like CPUs (for RSB and IBRS handling) */
+bool __init is_skylake_era(void)
 {
if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL &&
boot_cpu_data.x86 == 6) {
@@ -175,6 +179,7 @@ static bool __init is_skylake_era(void)
 
 static void __init spectre_v2_select_mitigation(void)
 {
+   bool full_retpoline = IS_ENABLED(CONFIG_RETPOLINE) && retp_compiler();
enum spectre_v2_mitigation_cmd cmd = spectre_v2_parse_cmdline();
enum spectre_v2_mitigation mode = SPECTRE_V2_NONE;
 
@@ -190,9 +195,25 @@ static void __init spectre_v2_select_mit
case SPECTRE_V2_CMD_NONE:
return;
 
+   case SPECTRE_V2_CMD_IBRS:
+   /* Command line requested IBRS. Try to enable it */
+   if (specctrl_force_enable_ibrs()) {
+   mode = SPECTRE_V2_IBRS;
+   goto set_mode;
+   }
+   /* FALLTRHU */
+
case SPECTRE_V2_CMD_FORCE:
/* FALLTRHU */
case SPECTRE_V2_CMD_AUTO:
+ 

[PATCH 31/35] x86/ibrs: Add new helper macros to save/restore MSR_IA32_SPEC_CTRL

[Peter Zijlstra]

From: Ashok Raj 

Add some helper macros to save/restore MSR_IA32_SPEC_CTRL.

  stop_indirect_branch_speculation_and_save() - saves the current
state and enables IBRS.

  restore_indirect_branch_speculation() - restores the previously
saved IBRS state.

[peterz: renaming and folding of logic from the kvm patches]

Cc: Asit Mallick 
Cc: Dave Hansen 
Cc: Arjan Van De Ven 
Cc: Tim Chen 
Cc: Linus Torvalds 
Cc: Andrea Arcangeli 
Cc: Andi Kleen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Andy Lutomirski 
Cc: Greg KH 
Cc: David Woodhouse 
Cc: Paolo Bonzini 
Signed-off-by: Ashok Raj 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/nospec-branch.h |   18 ++
 1 file changed, 18 insertions(+)

--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -232,6 +232,24 @@ static inline void restart_indirect_bran
native_wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_DISABLE_IBRS);
 }
 
+static inline u64 stop_indirect_branch_speculation_and_save(void)
+{
+   u64 val = 0;
+
+   if (static_cpu_has(X86_FEATURE_IBRS)) {
+   val = native_rdmsrl(MSR_IA32_SPEC_CTRL);
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_ENABLE_IBRS);
+   }
+
+   return val;
+}
+
+static inline void restore_indirect_branch_speculation(u64 val)
+{
+   if (static_cpu_has(X86_FEATURE_IBRS))
+   native_wrmsrl(MSR_IA32_SPEC_CTRL, val);
+}
+
 void specctrl_init_ibpb(void);
 
 static inline void indirect_branch_prediction_barrier(void)

Aslam Alaikum!

[Mr]

Aslam Alaikum!
Hi friend I am a staff in the bank, I want to transfer an abandoned sum of
USD15.5 Million to your Bank account. 40/percent will be your share.
No risk involved but keep it as secret. Contact me for more details.

Thanks
MR.SALLM --SALIF

[PATCH] x86/mce: Make machine check speculation protected

[Thomas Gleixner]

The machine check idtentry uses an indirect branch directly from the low
level code. This evades the speculation protection.

Replace it by a direct call into C code and issue the indirect call there
so the compiler can apply the proper speculation protection.

Signed-off-by: Thomas Gleixner 
---
 arch/x86/entry/entry_64.S|2 +-
 arch/x86/include/asm/traps.h |1 +
 arch/x86/kernel/cpu/mcheck/mce.c |5 +
 3 files changed, 7 insertions(+), 1 deletion(-)

--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -1264,7 +1264,7 @@ idtentry async_page_fault do_async_page_
 #endif
 
 #ifdef CONFIG_X86_MCE
-idtentry machine_check has_error_code=0
paranoid=1 do_sym=*machine_check_vector(%rip)
+idtentry machine_check do_mce  has_error_code=0
paranoid=1
 #endif
 
 /*
--- a/arch/x86/include/asm/traps.h
+++ b/arch/x86/include/asm/traps.h
@@ -88,6 +88,7 @@ dotraplinkage void do_simd_coprocessor_e
 #ifdef CONFIG_X86_32
 dotraplinkage void do_iret_error(struct pt_regs *, long);
 #endif
+dotraplinkage void do_mce(struct pt_regs *, long);
 
 static inline int get_si_code(unsigned long condition)
 {
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1785,6 +1785,11 @@ static void unexpected_machine_check(str
 void (*machine_check_vector)(struct pt_regs *, long error_code) =
unexpected_machine_check;
 
+dotraplinkage void do_mce(struct pt_regs *regs, long error_code)
+{
+   machine_check_vector(regs, error_code);
+}
+
 /*
  * Called for each booted CPU to set up machine checks.
  * Must be called with preempt off:

Re: [PATCH v5 43/44] ARM: da8xx-dt: switch to device tree clocks

[Sekhar Nori]

On Monday 08 January 2018 07:55 AM, David Lechner wrote:
> This removes all of the clock init code from da8xx-dt.c. This includes
> all of the OF_DEV_AUXDATA that was just used for looking up clocks.
> 
> Note: You need to have clocks defined in your device tree or your system
> won't boot after this patch.

I am not sure we can do this then, as we cannot break DT compatibility.

Thanks,
Sekhar

Re: [PATCH v5 33/44] ARM: davinci: switch to common clock framework

[Sekhar Nori]

On Monday 08 January 2018 07:53 AM, David Lechner wrote:
> diff --git a/arch/arm/mach-davinci/Makefile b/arch/arm/mach-davinci/Makefile
> index 4e81780..8a8f413 100644
> --- a/arch/arm/mach-davinci/Makefile
> +++ b/arch/arm/mach-davinci/Makefile
> @@ -5,7 +5,7 @@
>  #
>  
>  # Common objects
> -obj-y:= time.o clock.o serial.o psc.o \
> +obj-y:= time.o serial.o \
>  usb.o common.o sram.o aemif.o

The line break seems too early now.

Thanks,
Sekhar

Re: [net-next: PATCH 0/8] Armada 7k/8k PP2 ACPI support

[Andrew Lunn]

> I CC'ed Mika since he is more familiar with handling these bits of ACPI
> specs - I wonder whether this is a problem that cropped up on x86
> systems too.

Hi Lorenzo

There is nothing about MDIO, PHYs, Ethernet switches, etc in version
6.2 of the spec. If x86 has this, it must be after 6.2 was released.
I would not be too surprised if x86 has none of this. If you look at
the typical drives used on x86, i210, e1000e, ixgb, r8169, etc. They
are all PCI devices, and hide all this.

> I do not think there is one and only answer but there must be a single
> set of bindings and if the ACPI specs already cater for some of them
> we have to reuse them.

Agreed. Due diligence so far suggests there is nothing already
defined. But im a newbie to ACPI, so could be looking in the wrong
place. I really hope there is somebody like Rob Herring, the DT
maintainer, who keeps an eye on all ACPI talk and would tell us if we
are heading off in the wrong direction.

Andrew

Re: [PATCH v7 0/5] x86/KASLR: Add parameter kaslr_mem=nn[KMG]@ss[KMG]

[Luiz Capitulino]

On Thu, 18 Jan 2018 09:11:14 +0800
Chao Fan  wrote:

> On Wed, Jan 17, 2018 at 12:32:35PM -0500, Luiz Capitulino wrote:
> >On Wed, 17 Jan 2018 18:53:46 +0800
> >Chao Fan  wrote:
> >  
> >> ***Background:
> >> People reported that kaslr may randomly chooses some positions
> >> which are located in movable memory regions. This will break memory
> >> hotplug feature. 
> >> 
> >> And also on kvm guest with 4GB meory, the good unfragmented 1GB could
> >> be occupied by randomized kernel. It will cause hugetlb failing to
> >> allocate 1GB page. While kernel with 'nokaslr' has not such issue.
> >> This causes regression. Please see the discussion mail:
> >>https://lkml.org/lkml/2018/1/4/236
> >> 
> >> ***Solutions:
> >> Introduce a new kernel parameter 'kaslr_mem=nn@ss' to let users to
> >> specify the memory regions where kernel can be allowed to randomize
> >> safely.  
> >
> >I've tested this series with a 4GB KVM guest. With kaslr_mem=1G, I
> >got one 1GB page allocated 100% of the time in 85 boots. Without
> >kaslr_mem=, I got 3 failures in only 10 boots (that is, in 3 boots
> >I had no 1GB page allocated).
> >
> >So, this series solves the 1GB page problem for me.
> >  
> 
> 
> Thanks for Luiz's test.

Btw, my test tested a simple single case, but I think you can add:

Tested-by: Luiz Capitulino 

> 
> Thanks,
> Chao Fan
> 
> >> 
> >> E.g if 'movable_node' is spedified, we can use 'kaslr_mem=nn@ss' to
> >> tell KASLR where we can put kernel safely. Then KASLR code can avoid
> >> those movable regions and only choose those immovable regions
> >> specified.
> >> 
> >> For hugetlb case, users can always add 'kaslr_mem=1G' in kernel
> >> cmdline since the 0~1G is always fragmented region because of BIOS
> >> reserved area. Surely users can specify regions more precisely if
> >> they know system memory very well.
> >> 
> >> *** Issues need be discussed
> >> There are several issues I am not quite sure, please help review and
> >> give suggestions:
> >> 
> >> 1) Since there's already mem_avoid[] which stores the memory regions
> >> KASLR need avoid. For the regions KASLR can safely use, I name it as
> >> mem_usable[], not sure if it's appropriate. Or kaslr_mem[] directly?
> >> 
> >> 2) In v6, I made 'kaslr_mem=' as a kernel parameter which users can use
> >> to specify memory regions where kenrel can be extracted safely by
> >> 'kaslr_mem=nn@ss', or regions where we need avoid to extract kernel by
> >> 'kaslr_mem=nn!ss'. While later I rethink about it, seems
> >> 'kaslr_mem=nn@ss' can satisfy the current requirement, there's no need
> >> to introduce the 'kaslr_mem=nn!ss'. So I just take that
> >> 'kaslr_mem=nn!ss' handling patch off, may add it later if anyone think
> >> it's necessary. Any suggestions?
> >>https://www.spinics.net/lists/kernel/msg2698457.html
> >> 
> >> ***Test results:
> >>  - I did some tests for the memory hotplug issues. I specify the memory
> >>region in one node, then I found every time the kernel will be
> >>extracted to the memory of this node.
> >>  - Luiz said he will do some tests for the 1G huge page issue.
> >> 
> >> ***History
> >> v6->v7:
> >>  - Drop the unnecessary avoid part for now.
> >>  - Add document for the new parameter.
> >> 
> >> v5->v6:
> >>  - Add the last patch to save the avoid memory regions.
> >> 
> >> v4->v5:
> >>  - Change the problem reported by LKP
> >> Follow Dou's suggestion:
> >>  - Also return if match "movable_node" when parsing kernel commandline
> >>in handle_mem_filter without define CONFIG_MEMORY_HOTPLUG
> >> 
> >> v3->v4:
> >> Follow Kees's suggestion:
> >>  - Put the functions variables of immovable_mem to #ifdef
> >>CONFIG_MEMORY_HOTPLUG and change some code place
> >>  - Change the name of "process_mem_region" to "slots_count"
> >>  - Reanme the new function "process_immovable_mem" to "process_mem_region"
> >> Follow Baoquan's suggestion:
> >>  - Fail KASLR if "movable_node" specified without "immovable_mem"
> >>  - Ajust the code place of handling mem_region directely if no
> >>immovable_mem specified
> >> Follow Randy's suggestion:
> >>  - Change the mistake and add detailed description for the document.
> >> 
> >> v2->v3:
> >> Follow Baoquan He's suggestion:
> >>  - Change names of several functions.
> >>  - Add a new parameter "immovable_mem" instead of extending mvoable_node
> >>  - Use the clamp to calculate the memory intersecting, which makes
> >>logical more clear.
> >>  - Disable memory mirror if movable_node specified
> >> 
> >> v1->v2:
> >> Follow Dou Liyang's suggestion:
> >>  - Add the parse for movable_node=nn[KMG] without @ss[KMG]
> >>  - Fix the bug for more than one "movable_node=" specified
> >>  - Drop useless variables and use mem_vector region directely
> >>  - Add more comments.
> >> 
> >> Chao Fan (5):
> >>   x86/KASLR: Add kaslr_mem=nn[KMG]@ss[KMG]
> >>   x86/KASLR: Handle the memory regions specified in kaslr_mem
> 

[PATCH] ARC: Add a knob to control usage of dual-issue

[Alexey Brodkin]

HS48 core starts with dual-issue enabled but in some cases like
debugging as well as benchmarking it might be useful to disable
dual-issue for a particular run.

Note:
  1. To disable dual-issue user has to change a value of a global variable
 in target's memory right before start of Linu kernel execution
 (most probably via JTAG)

  2. Disabling happens very early on boot and to get it back enabled it's
 required to restart Linux kernel. I.e. with this change we don't allow
 toggling dual-issue state in random moments of run-time

Signed-off-by: Alexey Brodkin 
---
 arch/arc/kernel/setup.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 9d27331fe69a..cf97f7d88934 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -31,6 +31,8 @@
 
 #define FIX_PTR(x)  __asm__ __volatile__(";" : "+r"(x))
 
+int dual_issue_enable = 1;
+
 unsigned int intr_to_DE_cnt;
 
 /* Part of U-boot ABI: see head.S */
@@ -198,6 +200,17 @@ static void read_arc_build_cfg_regs(void)
if (cpu->core.family >= 0x54) {
unsigned int exec_ctrl;
 
+   if (!dual_issue_enable) {
+   /*
+* Note:
+*   1) Reset value in AUX_EXEC_CTRL is 0
+*   2) Reverse logic is used,
+*  i.e. by default (AUX_EXEC_CTRL=0)
+*  dual-issue is enabled.
+*/
+   write_aux_reg(AUX_EXEC_CTRL, 1);
+   }
+
READ_BCR(AUX_EXEC_CTRL, exec_ctrl);
cpu->extn.dual_enb = !(exec_ctrl & 1);
 
-- 
2.11.0

[PATCH] ARC: Enable fatal signals on boot for dev platforms

[Alexey Brodkin]

It's very convenient to have fatal signals enabled on developemnt
platform as this allows to catch problems that happen early in
user-space (like crashing init or dynamic loader).

Otherwise we may either enable it later from alive taregt console
by "echo 1 > /proc/sys/kernel/print-fatal-signals" but:
 1. We might be unfortunate enough to not reach working console
 2. Forget to enable fatal signals and miss something interesting

Given we're talking about development platforms here it shouldn't
be a problem if a bit more data gets printed to debug console.

Moreover this makes behavior of all our dev platforms predictable
as today some platforms already have it enabled and some don't -
which is way too inconvenient.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/boot/dts/axs101.dts  | 2 +-
 arch/arc/boot/dts/haps_hs_idu.dts | 2 +-
 arch/arc/boot/dts/nsim_700.dts| 2 +-
 arch/arc/boot/dts/nsim_hs.dts | 2 +-
 arch/arc/boot/dts/nsim_hs_idu.dts | 2 +-
 arch/arc/boot/dts/nsimosci.dts| 2 +-
 arch/arc/boot/dts/nsimosci_hs.dts | 2 +-
 arch/arc/boot/dts/nsimosci_hs_idu.dts | 2 +-
 8 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arc/boot/dts/axs101.dts b/arch/arc/boot/dts/axs101.dts
index 70aec7d6ca60..626b694c7be7 100644
--- a/arch/arc/boot/dts/axs101.dts
+++ b/arch/arc/boot/dts/axs101.dts
@@ -17,6 +17,6 @@
compatible = "snps,axs101", "snps,arc-sdp";
 
chosen {
-   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=tty0 console=ttyS3,115200n8 consoleblank=0 video=1280x720@60";
+   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=tty0 console=ttyS3,115200n8 consoleblank=0 video=1280x720@60 
print-fatal-signals=1";
};
 };
diff --git a/arch/arc/boot/dts/haps_hs_idu.dts 
b/arch/arc/boot/dts/haps_hs_idu.dts
index 215cddd0b63b..0c603308aeb3 100644
--- a/arch/arc/boot/dts/haps_hs_idu.dts
+++ b/arch/arc/boot/dts/haps_hs_idu.dts
@@ -22,7 +22,7 @@
};
 
chosen {
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=ttyS0,115200n8 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=ttyS0,115200n8 debug print-fatal-signals=1";
};
 
aliases {
diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
index 5ee96b067c08..ff2f2c70c545 100644
--- a/arch/arc/boot/dts/nsim_700.dts
+++ b/arch/arc/boot/dts/nsim_700.dts
@@ -17,7 +17,7 @@
interrupt-parent = <_intc>;
 
chosen {
-   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8";
+   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8 print-fatal-signals=1";
};
 
aliases {
diff --git a/arch/arc/boot/dts/nsim_hs.dts b/arch/arc/boot/dts/nsim_hs.dts
index 8d787b251f73..8e2489b16b0a 100644
--- a/arch/arc/boot/dts/nsim_hs.dts
+++ b/arch/arc/boot/dts/nsim_hs.dts
@@ -24,7 +24,7 @@
};
 
chosen {
-   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8";
+   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8 print-fatal-signals=1";
};
 
aliases {
diff --git a/arch/arc/boot/dts/nsim_hs_idu.dts 
b/arch/arc/boot/dts/nsim_hs_idu.dts
index 4f98ebf71fd8..ed12f494721d 100644
--- a/arch/arc/boot/dts/nsim_hs_idu.dts
+++ b/arch/arc/boot/dts/nsim_hs_idu.dts
@@ -15,7 +15,7 @@
interrupt-parent = <_intc>;
 
chosen {
-   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8";
+   bootargs = "earlycon=arc_uart,mmio32,0xc0fc1000,115200n8 
console=ttyARC0,115200n8 print-fatal-signals=1";
};
 
aliases {
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index 3c391ba565ed..7842e5eb4ab5 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24 
print-fatal-signals=1";
};
 
aliases {
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 14a727cbf4c9..b8838cf2b4ec 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   

Re: [PATCH] [net-next] net: sched: avoid uninitialized variable use

[Jiri Pirko]

Thu, Jan 18, 2018 at 02:17:28PM CET, a...@arndb.de wrote:
>gcc has identified a code path in which we pass uninitialized
>data into tc_dump_tfilter():
>
>net/sched/cls_api.c: In function 'tc_dump_tfilter':
>net/sched/cls_api.c:1268:8: error: 'parent' may be used uninitialized in this 
>function [-Werror=maybe-uninitialized]
>
>This initializes the variable to the value it had before the previous
>change.
>
>Fixes: 7960d1daf278 ("net: sched: use block index as a handle instead of qdisc 
>when block is shared")
>Signed-off-by: Arnd Bergmann 
>
>I don't know if my patch is the best way to address the issue, but
>if not, then at least it helps show what the warning is about
>and lets someone else come up with a better solution.

I already sent a fix for this:
http://patchwork.ozlabs.org/patch/862787/

Re: [PATCH v2] arm64: Branch predictor hardening for Cavium ThunderX2

[Will Deacon]

Hi JC,

On Tue, Jan 16, 2018 at 03:45:54PM -0800, Jayachandran C wrote:
> On Tue, Jan 16, 2018 at 04:52:53PM -0500, Jon Masters wrote:
> > On 01/09/2018 07:47 AM, Jayachandran C wrote:
> > 
> > > Use PSCI based mitigation for speculative execution attacks targeting
> > > the branch predictor. The approach is similar to the one used for
> > > Cortex-A CPUs, but in case of ThunderX2 we add another SMC call to
> > > test if the firmware supports the capability.
> > > 
> > > If the secure firmware has been updated with the mitigation code to
> > > invalidate the branch target buffer, we use the PSCI version call to
> > > invoke it.
> > 
> > What's the status of this patch currently? Previously you had suggested
> > to hold while the SMC got standardized, but then you seemed happy with
> > pulling in. What's the latest?
> 
> My understanding is that the SMC standardization is being worked on
> but will take more time, and the KPTI current patchset will go to
> mainline before that.
> 
> Given that, I would expect arm64 maintainers to pick up this patch for
> ThunderX2, but I have not seen any comments so far.
> 
> Will/Marc, please let me know if you are planning to pick this patch
> into the KPTI tree.

Are you really sure you want us to apply this? If we do, then you can't run
KVM guests anymore because your IMPDEF SMC results in an UNDEF being
injected (crash below).

I really think that you should just hook up the enable_psci_bp_hardening
callback like we've done for the Cortex CPUs. We can optimise this later
once the SMC standarisation work has been completed (which is nearly final
now and works in a backwards-compatible manner).

Will

--->8

[0.319123] Code: 2a080042 b8236885 29008829 17c0 (d403) 
[0.319125] Code: 2a080042 b8236885 29008829 17c0 (d403) 
[0.319147] Modules linked in:
[0.319152] CPU: 2 PID: 19 Comm: migration/2 Not tainted 
4.15.0-rc8-00103-g9409c1e175be-dirty #1
[0.319154] Hardware name: linux,dummy-virt (DT)
[0.319156] pstate: 0085 (nzcv daIf -PAN -UAO)
[0.319163] pc : __arm_smccc_smc+0x0/0x2c
[0.319166] lr : enable_tx2_psci_bp_hardening+0x6c/0x108
[0.319167] sp : 09dcbd30
[0.319168] x29: 09dcbd40 x28:  
[0.319171] x27: 0803bc88 x26: 0001 
[0.319174] x25: 08d13980 x24: 0907b575 
[0.319176] x23: 0001 x22:  
[0.319179] x21: 0803bd3c x20: 0803bd18 
[0.319181] x19: 089f2438 x18: 0030 
[0.319183] x17:  x16:  
[0.319185] x15:  x14: 0400 
[0.319187] x13: 0400 x12:  
[0.319189] x11:  x10: 0a00 
[0.319192] x9 : 09dcbd80 x8 : 8001f691b460 
[0.319194] x7 :  x6 :  
[0.319196] x5 :  x4 :  
[0.319198] x3 :  x2 :  
[0.319200] x1 : b0a0 x0 : c200ff00 
[0.319203] Process migration/2 (pid: 19, stack limit = 0x4aa336a5)
[0.319204] Call trace:
[0.319207]  __arm_smccc_smc+0x0/0x2c
[0.319211]  multi_cpu_stop+0x8c/0x110
[0.319213]  cpu_stopper_thread+0xac/0x120
[0.319219]  smpboot_thread_fn+0x158/0x240
[0.319220]  kthread+0x128/0x130
[0.319223]  ret_from_fork+0x10/0x18
[0.319226] Code: 2a080042 b8236885 29008829 17c0 (d403) 
[0.319230] ---[ end trace 169f08213b3163bb ]---
[0.319234] Internal error: undefined instruction: 0 [#2] PREEMPT SMP
[0.319259] note: migration/2[19] exited with preempt_count 1
[0.319284] Modules linked in:
[0.319288] CPU: 3 PID: 24 Comm: migration/3 Tainted: G  D  
4.15.0-rc8-00103-g9409c1e175be-dirty #1
[0.319289] Hardware name: linux,dummy-virt (DT)
[0.319291] pstate: 0085 (nzcv daIf -PAN -UAO)
[0.319295] pc : __arm_smccc_smc+0x0/0x2c
[0.319298] lr : enable_tx2_psci_bp_hardening+0x6c/0x108
[0.319298] sp : 09df3d30
[0.319300] x29: 09df3d40 x28:  
[0.319303] x27: 0803bc88 x26: 0001 
[0.319305] x25: 08d13980 x24: 0907b575 
[0.319307] x23: 0001 x22:  
[0.319310] x21: 0803bd3c x20: 0803bd18 
[0.319312] x19: 089f2438 x18: 0030 
[0.319314] x17:  x16:  
[0.319316] x15:  x14: 0400 
[0.319318] x13: 0400 x12: 0001 
[0.319321] x11: 9ad0065e x10: 0a00 
[0.319323] x9 : 09df3d80 x8 : 8001f691fa60 
[0.319325] x7 :  x6 :  
[0.319327] x5 :  x4 :  
[0.319329] x3 :  x2 :  
[0.319331] x1 : b0a0 x0 : 

Re: [GIT PULL] isolation: 1Hz residual tick offloading v3

[Luiz Capitulino]

On Thu, 18 Jan 2018 04:04:43 +0100
Frederic Weisbecker  wrote:

> On Wed, Jan 17, 2018 at 12:38:01PM -0500, Luiz Capitulino wrote:
> > On Tue, 16 Jan 2018 23:51:29 +0100
> > Frederic Weisbecker  wrote:
> >   
> > > On Tue, Jan 16, 2018 at 11:52:11AM -0500, Luiz Capitulino wrote:  
> > > > On Tue, 16 Jan 2018 16:41:00 +0100
> > > > Frederic Weisbecker  wrote:
> > > > > So isolcpus= is now the place where we control the isolation features
> > > > > and nohz is one of them.
> > > > 
> > > > That's the part I'm not very sure about. We've been advising users to
> > > > move away from isolcpus= when possible, but this very wanted 
> > > > nohz_offload
> > > > feature will force everyone back to using isolcpus= again.
> > > 
> > > Note "isolcpus=nohz" only implies nohz. You need to add "domain" to get
> > > the behaviour that you've been advising users against. We are simply
> > > reusing a kernel parameter that was abandoned to now control the isolation
> > > features that were disorganized and opaque behind nohz.
> > >   
> > > > 
> > > > I have the impression this series is trying to solve two problems:
> > > > 
> > > >  1. How (and where) we control the various isolation features in the
> > > > kernel
> > > 
> > > No, that has already been done in the previous merge window. We have a
> > > dedicated isolation subsystem now (kernel/sched/isolation.c) and
> > > an interface to control all these isolation features that were abusively 
> > > implied
> > > by nohz. The initial plan was to introduce "cpu_isolation=" but it looked 
> > > too much like
> > > "isolcpus=". Then in fact, why not using "isolcpus=" and give it a second 
> > > life.
> > > And there we are.  
> > 
> > OK, I get it now. But then series has to un-deprecate isolcpus= otherwise
> > it doesn't make sense to use it.  
> 
> Good point. Also I think you convinced me toward just applying that tick 
> offload
> on the existing nohz kernel parameter right away, that is, to both existing 
> "nohz_full="
> and "isolcpus=nohz".
> 
> After all that tick offload is an implementation detail.
> 
> Like you said if people complain about a regression, we can still fix it
> with a new option. But eventually I doubt this will be needed.
> 
> I'll respin with that.

Exciting times!

Btw, I do have this problem where I have a hog app on an isolated core
with isolcpus=nohz_offload,domain,... and I see top -d1 going from 100%
to 0% and then back from 0% to 100% every few seconds or so. I'll debug
it when you post the next version.

Re: [PATCH 2/5] pinctrl: stm32: add STM32F769 MCU support

[Patrice CHOTARD]

Hi Linus

It's a gentle reminder because this patch seems not yet merged in any of 
your pinctrl branch.

Thanks

Patrice

On 12/11/2017 09:54 AM, Alexandre Torgue wrote:
> This patch which adds STM32F769 pinctrl and GPIO support, relies on the
> generic STM32 pinctrl driver.
> 
> Signed-off-by: Alexandre Torgue 
> 
> diff --git a/drivers/pinctrl/stm32/Kconfig b/drivers/pinctrl/stm32/Kconfig
> index 7e1fe39..397f8c1 100644
> --- a/drivers/pinctrl/stm32/Kconfig
> +++ b/drivers/pinctrl/stm32/Kconfig
> @@ -27,6 +27,12 @@ config PINCTRL_STM32F746
>   default MACH_STM32F746
>   select PINCTRL_STM32
>   
> +config PINCTRL_STM32F769
> + bool "STMicroelectronics STM32F769 pin control" if COMPILE_TEST && 
> !MACH_STM32F769
> + depends on OF
> + default MACH_STM32F769
> + select PINCTRL_STM32
> +
>   config PINCTRL_STM32H743
>   bool "STMicroelectronics STM32H743 pin control" if COMPILE_TEST && 
> !MACH_STM32H743
>   depends on OF
> diff --git a/drivers/pinctrl/stm32/Makefile b/drivers/pinctrl/stm32/Makefile
> index d13ca35..7d63e4a 100644
> --- a/drivers/pinctrl/stm32/Makefile
> +++ b/drivers/pinctrl/stm32/Makefile
> @@ -6,4 +6,5 @@ obj-$(CONFIG_PINCTRL_STM32) += pinctrl-stm32.o
>   obj-$(CONFIG_PINCTRL_STM32F429) += pinctrl-stm32f429.o
>   obj-$(CONFIG_PINCTRL_STM32F469) += pinctrl-stm32f469.o
>   obj-$(CONFIG_PINCTRL_STM32F746) += pinctrl-stm32f746.o
> +obj-$(CONFIG_PINCTRL_STM32F769)  += pinctrl-stm32f769.o
>   obj-$(CONFIG_PINCTRL_STM32H743) += pinctrl-stm32h743.o
> diff --git a/drivers/pinctrl/stm32/pinctrl-stm32f769.c 
> b/drivers/pinctrl/stm32/pinctrl-stm32f769.c
> new file mode 100644
> index 000..f81c51c
> --- /dev/null
> +++ b/drivers/pinctrl/stm32/pinctrl-stm32f769.c
> @@ -0,0 +1,1827 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2017
> + * Author:  Alexandre Torgue  for 
> STMicroelectronics.
> + */
> +#include 
> +#include 
> +#include 
> +
> +#include "pinctrl-stm32.h"
> +
> +static const struct stm32_desc_pin stm32f769_pins[] = {
> + STM32_PIN(
> + PINCTRL_PIN(0, "PA0"),
> + STM32_FUNCTION(0, "GPIOA0"),
> + STM32_FUNCTION(2, "TIM2_CH1 TIM2_ETR"),
> + STM32_FUNCTION(3, "TIM5_CH1"),
> + STM32_FUNCTION(4, "TIM8_ETR"),
> + STM32_FUNCTION(8, "USART2_CTS"),
> + STM32_FUNCTION(9, "UART4_TX"),
> + STM32_FUNCTION(11, "SAI2_SD_B"),
> + STM32_FUNCTION(12, "ETH_MII_CRS"),
> + STM32_FUNCTION(16, "EVENTOUT"),
> + STM32_FUNCTION(17, "ANALOG")
> + ),
> + STM32_PIN(
> + PINCTRL_PIN(1, "PA1"),
> + STM32_FUNCTION(0, "GPIOA1"),
> + STM32_FUNCTION(2, "TIM2_CH2"),
> + STM32_FUNCTION(3, "TIM5_CH2"),
> + STM32_FUNCTION(8, "USART2_RTS"),
> + STM32_FUNCTION(9, "UART4_RX"),
> + STM32_FUNCTION(10, "QUADSPI_BK1_IO3"),
> + STM32_FUNCTION(11, "SAI2_MCLK_B"),
> + STM32_FUNCTION(12, "ETH_MII_RX_CLK ETH_RMII_REF_CLK"),
> + STM32_FUNCTION(15, "LCD_R2"),
> + STM32_FUNCTION(16, "EVENTOUT"),
> + STM32_FUNCTION(17, "ANALOG")
> + ),
> + STM32_PIN(
> + PINCTRL_PIN(2, "PA2"),
> + STM32_FUNCTION(0, "GPIOA2"),
> + STM32_FUNCTION(2, "TIM2_CH3"),
> + STM32_FUNCTION(3, "TIM5_CH3"),
> + STM32_FUNCTION(4, "TIM9_CH1"),
> + STM32_FUNCTION(8, "USART2_TX"),
> + STM32_FUNCTION(9, "SAI2_SCK_B"),
> + STM32_FUNCTION(12, "ETH_MDIO"),
> + STM32_FUNCTION(13, "MDIOS_MDIO"),
> + STM32_FUNCTION(15, "LCD_R1"),
> + STM32_FUNCTION(16, "EVENTOUT"),
> + STM32_FUNCTION(17, "ANALOG")
> + ),
> + STM32_PIN(
> + PINCTRL_PIN(3, "PA3"),
> + STM32_FUNCTION(0, "GPIOA3"),
> + STM32_FUNCTION(2, "TIM2_CH4"),
> + STM32_FUNCTION(3, "TIM5_CH4"),
> + STM32_FUNCTION(4, "TIM9_CH2"),
> + STM32_FUNCTION(8, "USART2_RX"),
> + STM32_FUNCTION(10, "LCD_B2"),
> + STM32_FUNCTION(11, "OTG_HS_ULPI_D0"),
> + STM32_FUNCTION(12, "ETH_MII_COL"),
> + STM32_FUNCTION(15, "LCD_B5"),
> + STM32_FUNCTION(16, "EVENTOUT"),
> + STM32_FUNCTION(17, "ANALOG")
> + ),
> + STM32_PIN(
> + PINCTRL_PIN(4, "PA4"),
> + STM32_FUNCTION(0, "GPIOA4"),
> + STM32_FUNCTION(6, "SPI1_NSS I2S1_WS"),
> + STM32_FUNCTION(7, "SPI3_NSS I2S3_WS"),
> + STM32_FUNCTION(8, "USART2_CK"),
> + STM32_FUNCTION(9, "SPI6_NSS"),
> + STM32_FUNCTION(13, "OTG_HS_SOF"),
> + STM32_FUNCTION(14, "DCMI_HSYNC"),
> + STM32_FUNCTION(15, "LCD_VSYNC"),
> + STM32_FUNCTION(16, "EVENTOUT"),
> + 

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Greg Kroah-Hartman]

On Thu, Jan 18, 2018 at 02:01:28PM +0100, Dmitry Vyukov wrote:
> On Thu, Jan 18, 2018 at 2:09 AM, Theodore Ts'o  wrote:
> > On Wed, Jan 17, 2018 at 04:21:13PM -0800, Alexei Starovoitov wrote:
> >>
> >> If syzkaller can only test one tree than linux-next should be the one.
> >
> > Well, there's been some controversy about that.  The problem is that
> > it's often not clear if this is long-standing bug, or a bug which is
> > in a particular subsystem tree --- and if so, *which* subsystem tree,
> > etc.  So it gets blasted to linux-kernel, and to get_maintainer.pl,
> > which is often not accurate --- since the location of the crash
> > doesn't necessarily point out where the problem originated, and hence
> > who should look at the syzbot report.  And so this has caused
> > some irritation.
> 
> 
> Re set of tested trees.
> 
> We now have an interesting spectrum of opinions.
> 
> Some assorted thoughts on this:
> 
> 1. First, "upstream is clean" won't happen any time soon. There are
> several reasons for this:
>  - Currently syzkaller only tests a subset of subsystems that it knows
> how to test, even the ones that it tests it tests poorly. Over time
> it's improved to test most subsystems and existing subsystems better.
> Just few weeks ago I've added some descriptions for crypto subsystem
> and it uncovered 20+ old bugs.
>  - syzkaller is guided, genetic fuzzer over time it leans how to do
> more complex things by small steps. It takes time.
>  - We have more bug detection tools coming: LEAKCHECK, KMSAN (uninit
> memory), KTSAN (data races).
>  - generic syzkaller smartness will be improved over time.
>  - it will get more CPU resources.
> Effect of all of these things is multiplicative: we test more code,
> smarter, with more bug-detection tools, with more resources. So I
> think we need to plan for a mix of old and new bugs for foreseeable
> future.

That's fine, but when you test Linus's tree, we "know" you are hitting
something that really is an issue, and it's not due to linux-next
oddities.

When I see a linux-next report, and it looks "odd", my default reaction
is "ugh, must be a crazy patch in some other subsystem, I _know_ my code
in linux-next is just fine." :)

> 2. get_maintainer.pl and mix of old and new bugs was mentioned as
> harming attribution. I don't see what will change when/if we test only
> upstream. Then the same mix of old/new bugs will be detected just on
> upstream, with all of the same problems for old/new, maintainers,
> which subsystem, etc. I think the amount of bugs in the kernel is
> significant part of the problem, but the exact boundary where we
> decide to start killing them won't affect number of bugs.

I don't worry about that, the traceback should tell you a lot, and even
when that is wrong (i.e. warnings thrown up by sysfs core calls that are
obviously not a sysfs issue, but rather a subsystem issue), it's easy to
see.

> 3. If we test only upstream, we increase chances of new security bugs
> sinking into releases. We sure could raise perceived security value of
> the bugs by keeping them private, letting them sink into release,
> letting them sink into distros, and then reporting a high-profile
> vulnerability. I think that's wrong. There is something broken with
> value measuring in security community. Bug that is killed before
> sinking into any release is the highest impact thing. As Alexei noted,
> fixing bugs es early as possible also reduces fix costs, backporting
> burden, etc. This also can eliminate need in bisection in some cases,
> say if you accepted a large change to some files and a bunch of
> crashes appears for these files on your tree soon, it's obvious what
> happens.

I agree, this is an issue, but I think you have a lot of "low hanging
fruit" in Linus's tree left to find.  Testing linux-next is great, but
the odds of something "new" being added there for your type of testing
right now is usually pretty low, right?

thanks,

greg k-h

net: r8169: a question of memory barrier in the r8169 driver

[Jia-Ju Bai]

In the rt8169 driver, the function "rtl_tx" uses "smp_mb" to sync the 
writing operation with rtl8169_start_xmit:

if (tp->dirty_tx != dirty_tx) {
tp->dirty_tx = dirty_tx;
smp_mb();
...
}
The function rtl8169_start_xmit reads tp->dirty_tx in TX_FRAGS_READY_FOR:
if (unlikely(!TX_FRAGS_READY_FOR(tp, skb_shinfo(skb)->nr_frags))) {
netif_err(tp, drv, dev, "BUG! Tx Ring full when queue awake!\n");
goto err_stop_0;
}
But there is no memory barrier around this code.

Is there a possible data race here?
If not, how this data race is avoided?


Thanks,
Jia-Ju Bai

Re: [PATCH 1/2] kconfig: use default 'yy' prefix for lexer and parser

[Masahiro Yamada]

2018-01-12 9:58 GMT+09:00 Masahiro Yamada :
> Flex and Bison provide an option to change the prefix of globally-
> visible symbols.  This is useful to link multiple lexers and/or
> parsers into the same executable.  However, Kconfig (and any other
> host programs in kernel) uses a single lexer and parser.  I do not
> see a good reason to change the default 'yy' prefix.
>
> Signed-off-by: Masahiro Yamada 
> ---
>

Applied both patches to linux-kbuild/kconfig.



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library

[Arnaldo Carvalho de Melo]

Em Thu, Jan 18, 2018 at 02:59:48PM +0100, Jiri Olsa escreveu:
> On Thu, Jan 18, 2018 at 10:41:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > Shouldn't libopencsd be treated like libbabeltrace was before
> > the required version was widely available in distros?

> > I.e. these csets should have the rationale for that:

> > Enabling it once it became widely available:

> >24787afbcd01 ("perf tools: Enable LIBBABELTRACE by default")

> > Disabling it because we would need to get things from tarballs/git
> > repos, build it in our machines, as requested by Ingo:

> >   6ab2b762befd ("perf build: Disable libbabeltrace check by default")
> 
> I think at that time we did not have a way to hide the check,
> now we have FEATURE_DISPLAY seprated so we can still check
> for it, but users won't be bothered with [ FAIL ] output

Ok, users won't be bothered with the fail output, but we tried hard to
get the build fast by having it only test for things that are widely
available, right? I.e. if we know something is not widely available then
we better not try to build with it and get faster builds, wasn't that
part of the rationale in the babeltrace case?

If one has to build from sources some library, then its not a problem to
have in the make command line a LIBOPENCSD=1 switch?

- Arnaldo

Re: [PATCH net-next 3/5] net: hns3: add ethtool -p support for phy device

[Andrew Lunn]

> +static int hclge_set_led_status_phy(struct phy_device *phydev, int value)
> +{
> + int ret, cur_page;
> +
> + mutex_lock(>lock);
> +
> + ret = phy_read(phydev, HCLGE_PHY_PAGE_REG);
> + if (ret < 0)
> + goto out;
> + else
> + cur_page = ret;
> +
> + ret = phy_write(phydev, HCLGE_PHY_PAGE_REG, HCLGE_PHY_PAGE_LED);
> + if (ret)
> + goto out;
> +
> + ret = phy_write(phydev, HCLGE_LED_FC_REG, value);
> + if (ret)
> + goto out;
> +
> + ret = phy_write(phydev, HCLGE_PHY_PAGE_REG, cur_page);
> +
> +out:
> + mutex_unlock(>lock);
> + return ret;
> +}

Sorry, but NACK.

Please add an interface to phylib and the phy driver you are using to
do this.

>  #define HCLGE_PHY_PAGE_MDIX  0
>  #define HCLGE_PHY_PAGE_COPPER0
> +#define HCLGE_PHY_PAGE_LED   3
>  
>  /* Page Selection Reg. */
>  #define HCLGE_PHY_PAGE_REG   22
> @@ -73,6 +74,15 @@
>  /* Copper Specific Status Register */
>  #define HCLGE_PHY_CSS_REG17
>  
> +/* LED Function Control Register */
> +#define HCLGE_LED_FC_REG 16
> +
> +/* LED Polarity Control Register */
> +#define HCLGE_LED_PC_REG 17
> +
> +#define HCLGE_LED_FORCE_ON   9
> +#define HCLGE_LED_FORCE_OFF  8
> +

By the looks of these defines, you assume you have a Marvell PHY.
Please make this generic so anybody with a Marvell PHY can use it.

   Andrew

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[JeffyChen]

Hi Robin,

On 01/18/2018 08:27 PM, Robin Murphy wrote:




Is it worth using the clk_bulk_*() APIs for this? At a glance, most of
the code being added here appears to duplicate what those functions
already do (but I'm no clk API expert, for sure).
right, i think it's doable, the clk_bulk APIs are very helpful. i think 
we didn't use that is because this patch were wrote for the chromeos 4.4 
kernel, which doesn't have clk_bulk yet:)


will do it in the next version, thanks.


Robin.

Re: [PATCH v6 85/99] btrfs: Remove unused spinlock

[David Sterba]

On Wed, Jan 17, 2018 at 12:21:49PM -0800, Matthew Wilcox wrote:
> From: Matthew Wilcox 
> 
> The reada_lock in struct btrfs_device was only initialised, and not
> actually used.  That's good because there's another lock also called
> reada_lock in the btrfs_fs_info that was quite heavily used.  Remove
> this one.
> 
> Signed-off-by: Matthew Wilcox 

I'll pick this one now, thanks.

Re: [PATCH] [net-next] net: sched: avoid uninitialized variable use

[Jiri Pirko]

Thu, Jan 18, 2018 at 03:19:14PM CET, a...@arndb.de wrote:
>On Thu, Jan 18, 2018 at 2:49 PM, Jiri Pirko  wrote:
>> Thu, Jan 18, 2018 at 02:17:28PM CET, a...@arndb.de wrote:
>>>gcc has identified a code path in which we pass uninitialized
>>>data into tc_dump_tfilter():
>>>
>>>net/sched/cls_api.c: In function 'tc_dump_tfilter':
>>>net/sched/cls_api.c:1268:8: error: 'parent' may be used uninitialized in 
>>>this function [-Werror=maybe-uninitialized]
>>>
>>>This initializes the variable to the value it had before the previous
>>>change.
>>>
>>>Fixes: 7960d1daf278 ("net: sched: use block index as a handle instead of 
>>>qdisc when block is shared")
>>>Signed-off-by: Arnd Bergmann 
>>>
>>>I don't know if my patch is the best way to address the issue, but
>>>if not, then at least it helps show what the warning is about
>>>and lets someone else come up with a better solution.
>>
>> I already sent a fix for this:
>> http://patchwork.ozlabs.org/patch/862787/
>
>Ok. I've looked at your patch for way too long now and still don't see how
>you've shown it to be correct. Shouldn't there be a at least a comment
>to explain why zero is an appropriate initialization value in that case?

Okay. Will add comment.


>
>  Arnd

[PATCH] ARM: dts: at91: sama5d4: fix pinctrl compatible string

[Ludovic Desroches]

From: Santiago Esteban 

The compatible string is incorrect. Add atmel,sama5d3-pinctrl since
it's the appropriate compatible string. Remove the
atmel,at91rm9200-pinctrl compatible string, this fallback is
useless, there are too many changes.

Signed-off-by: Santiago Esteban 
Signed-off-by: Ludovic Desroches 
Cc: sta...@vger.kernel.org #v3.18
---
 arch/arm/boot/dts/sama5d4.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index 373b3621b536..c7105096c623 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -1379,7 +1379,7 @@
pinctrl@fc06a000 {
#address-cells = <1>;
#size-cells = <1>;
-   compatible = "atmel,at91sam9x5-pinctrl", 
"atmel,at91rm9200-pinctrl", "simple-bus";
+   compatible = "atmel,sama5d3-pinctrl", 
"atmel,at91sam9x5-pinctrl", "simple-bus";
ranges = <0xfc068000 0xfc068000 0x100
  0xfc06a000 0xfc06a000 0x4000>;
/* WARNING: revisit as pin spec has changed */
-- 
2.12.2

Re: [PATCH] iommu/of: Only do IOMMU lookup for available ones

[Will Deacon]

On Wed, Jan 17, 2018 at 02:28:08PM +0100, Joerg Roedel wrote:
> On Wed, Jan 03, 2018 at 02:09:20PM +0800, Jeffy Chen wrote:
> > The for_each_matching_node_and_match() would return every matching
> > nodes including unavailable ones.
> > 
> > It's pointless to init unavailable IOMMUs, so add a sanity check to
> > avoid that.
> > 
> > Signed-off-by: Jeffy Chen 
> > ---
> > 
> >  drivers/iommu/of_iommu.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
> > index 50947ebb6d17..6f7456caa30d 100644
> > --- a/drivers/iommu/of_iommu.c
> > +++ b/drivers/iommu/of_iommu.c
> > @@ -240,6 +240,9 @@ static int __init of_iommu_init(void)
> > for_each_matching_node_and_match(np, matches, ) {
> > const of_iommu_init_fn init_fn = match->data;
> >  
> > +   if (!of_device_is_available(np))
> > +   continue;
> > +
> 
> Makes sense to me, but I'd like to have an OK from Robin or Will (added
> to Cc) before applying this.

I don't think this patch makes a lot of sense in isolation: the SMMU drivers
themselves will likely still probe, and it's unclear what we should about
DMA when an IOMMU is not deemed to be available. See:

https://patchwork.kernel.org/patch/9681211/

Jeffy -- are you solving a real issue here, or is this just an attempt at
some cleanup?

Will

[PATCH v3 09/14] ARM: dts: stm32: Enable SDIO controller on stm32f469 disco board

[patrice.chotard]

From: Andrea Merello 

This patch adds SDIO-related DT nodes required by stm32f469 board

There is a hardware issue on these boards, it misses a pullup on
the GPIO line used as card detect to allow correct SD card
detection. To allow correct card detection "broken-cd" property
is used.

Signed-off-by: Andrea Merello 
Signed-off-by: Alexandre TORGUE 
Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ none


 arch/arm/boot/dts/stm32f469-disco.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f469-disco.dts 
b/arch/arm/boot/dts/stm32f469-disco.dts
index 318fb12..ebb97c3 100644
--- a/arch/arm/boot/dts/stm32f469-disco.dts
+++ b/arch/arm/boot/dts/stm32f469-disco.dts
@@ -66,6 +66,13 @@
serial0 = 
};
 
+   mmc_vcard: mmc_vcard {
+   compatible = "regulator-fixed";
+   regulator-name = "mmc_vcard";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+
soc {
dma-ranges = <0xc000 0x0 0x1000>;
};
@@ -120,6 +127,18 @@
};
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_vcard>;
+   cd-gpios = < 2 0>;
+   cd-inverted;
+   broken-cd;
+   pinctrl-names = "default", "opendrain";
+   pinctrl-0 = <_pins>;
+   pinctrl-1 = <_pins_od>;
+   bus-width = <4>;
+};
+
  {
pinctrl-0 = <_pins_a>;
pinctrl-names = "default";
-- 
1.9.1

[PATCH 08/35] objtool: Implement jump_assert for _static_cpu_has()

[Peter Zijlstra]

Unlike the jump_label bits, static_cpu_has is implemented with
alternatives. We use the new type field to distinguish them from any
other alternatives

Like jump_labels, make static_cpu_has set static_jump_dest on the
instructions after the static branch such that we can assert on it.

Cc: Thomas Gleixner 
Cc: Borislav Petkov 
Cc: Josh Poimboeuf 
Signed-off-by: Peter Zijlstra (Intel) 
---
 tools/objtool/check.c   |   21 +
 tools/objtool/special.c |   26 +++---
 tools/objtool/special.h |1 +
 3 files changed, 37 insertions(+), 11 deletions(-)

--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -636,6 +636,12 @@ static int handle_group_alt(struct objto
fake_jump->ignore = true;
 
if (!special_alt->new_len) {
+   /*
+* The NOP case for _static_cpu_has()
+*/
+   if (special_alt->static_cpu_has)
+   fake_jump->jump_dest->static_jump_dest = true;
+
*new_insn = fake_jump;
return 0;
}
@@ -664,6 +670,21 @@ static int handle_group_alt(struct objto
  insn->sec, insn->offset);
return -1;
}
+
+   if (special_alt->static_cpu_has) {
+   if (insn->type != INSN_JUMP_UNCONDITIONAL) {
+   WARN_FUNC("not an unconditional jump in 
_static_cpu_has()",
+ insn->sec, insn->offset);
+   }
+   if (insn->jump_dest == fake_jump) {
+   WARN_FUNC("jump inside alternative for 
_static_cpu_has()",
+ insn->sec, insn->offset);
+   }
+   /*
+* The JMP+disp case for _static_cpu_has()
+*/
+   insn->jump_dest->static_jump_dest = true;
+   }
}
 
if (!last_new_insn) {
--- a/tools/objtool/special.c
+++ b/tools/objtool/special.c
@@ -40,6 +40,10 @@
 #define ALT_FEATURE_OFFSET 8
 #define ALT_ORIG_LEN_OFFSET10
 #define ALT_NEW_LEN_OFFSET 11
+#define ALT_TYPE_OFFSET13
+
+#define ALT_TYPE_DEFAULT   0
+#define ALT_TYPE_STATIC_CPU_HAS1
 
 #define X86_FEATURE_POPCNT (4*32+23)
 
@@ -48,7 +52,6 @@ struct special_entry {
bool group, jump_or_nop;
unsigned char size, orig, new;
unsigned char orig_len, new_len; /* group only */
-   unsigned char feature; /* ALTERNATIVE macro CPU feature */
 };
 
 struct special_entry entries[] = {
@@ -60,7 +63,6 @@ struct special_entry entries[] = {
.orig_len = ALT_ORIG_LEN_OFFSET,
.new = ALT_NEW_OFFSET,
.new_len = ALT_NEW_LEN_OFFSET,
-   .feature = ALT_FEATURE_OFFSET,
},
{
.sec = "__jump_table",
@@ -84,24 +86,23 @@ static int get_alt_entry(struct elf *elf
 {
struct rela *orig_rela, *new_rela;
unsigned long offset;
+   void *data;
 
offset = idx * entry->size;
+   data = sec->data->d_buf + offset;
 
alt->group = entry->group;
alt->jump_or_nop = entry->jump_or_nop;
 
if (alt->group) {
-   alt->orig_len = *(unsigned char *)(sec->data->d_buf + offset +
-  entry->orig_len);
-   alt->new_len = *(unsigned char *)(sec->data->d_buf + offset +
- entry->new_len);
-   }
-
-   if (entry->feature) {
unsigned short feature;
+   unsigned char type;
 
-   feature = *(unsigned short *)(sec->data->d_buf + offset +
- entry->feature);
+   alt->orig_len = *(unsigned char *)(data + entry->orig_len);
+   alt->new_len = *(unsigned char *)(data + entry->new_len);
+
+   feature = *(unsigned short *)(data + ALT_FEATURE_OFFSET);
+   type = *(unsigned char *)(data + ALT_TYPE_OFFSET);
 
/*
 * It has been requested that we don't validate the !POPCNT
@@ -110,6 +111,9 @@ static int get_alt_entry(struct elf *elf
 */
if (feature == X86_FEATURE_POPCNT)
alt->skip_orig = true;
+
+   if (type == ALT_TYPE_STATIC_CPU_HAS)
+   alt->static_cpu_has = true;
}
 
orig_rela = find_rela_by_dest(sec, offset + entry->orig);
--- a/tools/objtool/special.h
+++ b/tools/objtool/special.h
@@ -27,6 +27,7 @@ struct special_alt {
bool group;
bool skip_orig;
bool jump_or_nop;
+   bool static_cpu_has;
 
struct section *orig_sec;
unsigned long orig_off;

Re: [PATCH] PCI: dwc: dra7xx: add back CONFIG_PCI dependency for endpoint

[Niklas Cassel]

On Thu, Jan 18, 2018 at 02:15:54PM +0100, Arnd Bergmann wrote:
> It was a nice idea to split out the PCI host and endpoint mode configuration
> into separate options. Unfortunately it doesn't build:
> 
> drivers/pci/dwc/pci-dra7xx.c:229:11: error: 'pci_irqd_intx_xlate' undeclared 
> here (not in a function)
> 
> This is certainly a fixable problem, but since it's clear that this
> configuration was never tested, let's maybe revert back to the
> dependency for now, until it can be done in a way that works
> better.

Hello Arnd,

That is not true :( I did test..

git checkout b052835c6385
disable CONFIG_PCI
make
works like a charm :P

Commit 524d59f6e30a ("PCI: dra7xx: Fix legacy INTD IRQ handling"),
which was merged after my commit, added a dependency towards
pci_irqd_intx_xlate.

It might be a bit unfortunately that commit 489f8fe6aa71
("PCI: dwc: dra7xx: Help compiler to remove unused code"),
a commit that you helped me with Arnd, was placed after
b052835c6385 ("PCI: dwc: dra7xx: Refactor Kconfig and Makefile
handling for host/ep mode") instead of before, in my patch
series order.

However, since pci_irqd_intx_xlate is only defined inside
CONFIG_PCI, even 489f8fe6aa71 will not help.

Not completely sure about this, but perhaps a better fix is:

+++ b/include/linux/pci.h
@@ -1686,6 +1686,12 @@ static inline int pci_get_new_domain_nr(void) { return 
-ENOSYS; }
 #define dev_is_pf(d) (false)
 static inline bool pci_acs_enabled(struct pci_dev *pdev, u16 acs_flags)
 { return false; }
+static inline int pci_irqd_intx_xlate(struct irq_domain *d,
+ struct device_node *node,
+ const u32 *intspec,
+ unsigned int intsize,
+ unsigned long *out_hwirq,
+ unsigned int *out_type) { return 0; }
 #endif /* CONFIG_PCI */
 
 /* Include architecture-dependent settings and functions */


And a 'Fixes:' tag that references 524d59f6e30a

Regards,
Niklas

> 
> Fixes: b052835c6385 ("PCI: dwc: dra7xx: Refactor Kconfig and Makefile 
> handling for host/ep mode")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/pci/dwc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/dwc/Kconfig b/drivers/pci/dwc/Kconfig
> index 0fb96c7754de..540419527a92 100644
> --- a/drivers/pci/dwc/Kconfig
> +++ b/drivers/pci/dwc/Kconfig
> @@ -36,7 +36,7 @@ config PCI_DRA7XX_HOST
>  config PCI_DRA7XX_EP
>   bool "TI DRA7xx PCIe controller Endpoint Mode"
>   depends on SOC_DRA7XX || COMPILE_TEST
> - depends on PCI_ENDPOINT
> + depends on PCI && PCI_ENDPOINT
>   depends on OF && HAS_IOMEM && TI_PIPE3
>   select PCIE_DW_EP
>   select PCI_DRA7XX
> -- 
> 2.9.0
> 

[PATCH 35/35] x86/nospec: Add static assertions

[Peter Zijlstra]

These sites must not end up under dynamic conditions because then it
could be speculated across. Ensure objtools verifies this.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/nospec-branch.h |   19 +++
 1 file changed, 15 insertions(+), 4 deletions(-)

--- a/arch/x86/include/asm/nospec-branch.h
+++ b/arch/x86/include/asm/nospec-branch.h
@@ -3,6 +3,8 @@
 #ifndef __NOSPEC_BRANCH_H__
 #define __NOSPEC_BRANCH_H__
 
+#include 
+
 #include 
 #include 
 #include 
@@ -222,14 +224,18 @@ bool is_skylake_era(void);
 
 static inline void stop_indirect_branch_speculation(void)
 {
-   if (static_cpu_has(X86_FEATURE_IBRS))
+   if (static_cpu_has(X86_FEATURE_IBRS)) {
+   arch_static_assert();
native_wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_ENABLE_IBRS);
+   }
 }
 
 static inline void restart_indirect_branch_speculation(void)
 {
-   if (static_cpu_has(X86_FEATURE_IBRS))
+   if (static_cpu_has(X86_FEATURE_IBRS)) {
+   arch_static_assert();
native_wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_DISABLE_IBRS);
+   }
 }
 
 static inline u64 stop_indirect_branch_speculation_and_save(void)
@@ -237,6 +243,7 @@ static inline u64 stop_indirect_branch_s
u64 val = 0;
 
if (static_cpu_has(X86_FEATURE_IBRS)) {
+   arch_static_assert();
val = native_rdmsrl(MSR_IA32_SPEC_CTRL);
native_wrmsrl(MSR_IA32_SPEC_CTRL, SPEC_CTRL_ENABLE_IBRS);
}
@@ -246,16 +253,20 @@ static inline u64 stop_indirect_branch_s
 
 static inline void restore_indirect_branch_speculation(u64 val)
 {
-   if (static_cpu_has(X86_FEATURE_IBRS))
+   if (static_cpu_has(X86_FEATURE_IBRS)) {
+   arch_static_assert();
native_wrmsrl(MSR_IA32_SPEC_CTRL, val);
+   }
 }
 
 void specctrl_init_ibpb(void);
 
 static inline void indirect_branch_prediction_barrier(void)
 {
-   if (static_cpu_has(X86_FEATURE_IBPB))
+   if (static_cpu_has(X86_FEATURE_IBPB)) {
+   arch_static_assert();
native_wrmsrl(MSR_IA32_PRED_CMD, PRED_CMD_IBPB);
+   }
 }
 
 #endif /* __ASSEMBLY__ */

[PATCH 14/35] x86: Annotate indirect jump in head_64.S

[Peter Zijlstra]

The objtool retpoline validation found this indirect jump. Seeing how
its on CPU bringup before we run userspace it should be safe, annotate
it.

Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kernel/head_64.S |2 ++
 1 file changed, 2 insertions(+)

--- a/arch/x86/kernel/head_64.S
+++ b/arch/x86/kernel/head_64.S
@@ -23,6 +23,7 @@
 #include 
 #include "../entry/calling.h"
 #include 
+#include 
 
 #ifdef CONFIG_PARAVIRT
 #include 
@@ -134,6 +135,7 @@ ENTRY(secondary_startup_64)
 
/* Ensure I am executing from virtual addresses */
movq$1f, %rax
+   ANNOTATE_RETPOLINE_SAFE
jmp *%rax
 1:
UNWIND_HINT_EMPTY

[PATCH 05/35] x86: Add a type field to alt_instr

[Peter Zijlstra]

Add a type field to the alternative description. For now this will be
used to annotate static_cpu_has() but possible future uses include
using it to implement alternative alignment and special NOP handling.

Suggested-by: Borislav Petkov 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/alternative-asm.h |3 ++-
 arch/x86/include/asm/alternative.h |6 +-
 arch/x86/include/asm/cpufeature.h  |2 ++
 tools/objtool/special.c|2 +-
 4 files changed, 10 insertions(+), 3 deletions(-)

--- a/arch/x86/include/asm/alternative-asm.h
+++ b/arch/x86/include/asm/alternative-asm.h
@@ -25,13 +25,14 @@
  * enough information for the alternatives patching code to patch an
  * instruction. See apply_alternatives().
  */
-.macro altinstruction_entry orig alt feature orig_len alt_len pad_len
+.macro altinstruction_entry orig alt feature orig_len alt_len pad_len type=0
.long \orig - .
.long \alt - .
.word \feature
.byte \orig_len
.byte \alt_len
.byte \pad_len
+   .byte \type
 .endm
 
 /*
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -45,6 +45,8 @@
 #define LOCK_PREFIX ""
 #endif
 
+#define ALT_TYPE_DEFAULT   0
+
 struct alt_instr {
s32 instr_offset;   /* original instruction */
s32 repl_offset;/* offset to replacement instruction */
@@ -52,6 +54,7 @@ struct alt_instr {
u8  instrlen;   /* length of original instruction */
u8  replacementlen; /* length of new instruction */
u8  padlen; /* length of build-time padding */
+   u8  type;   /* type of alternative */
 } __packed;
 
 /*
@@ -127,7 +130,8 @@ static inline int alternatives_text_rese
" .word " __stringify(feature) "\n" /* feature bit */ \
" .byte " alt_total_slen "\n"   /* source len  */ \
" .byte " alt_rlen(num) "\n"/* replacement len */ \
-   " .byte " alt_pad_len "\n"  /* pad len */
+   " .byte " alt_pad_len "\n"  /* pad len */ \
+   " .byte 0 \n"   /* type */
 
 #define ALTINSTR_REPLACEMENT(newinstr, feature, num)   /* replacement */ \
b_replacement(num)":\n\t" newinstr "\n" e_replacement(num) ":\n\t"
--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -157,6 +157,7 @@ static __always_inline __pure bool _stat
 " .byte 3b - 1b\n" /* src len */
 " .byte 5f - 4f\n" /* repl len */
 " .byte 3b - 2b\n" /* pad len */
+" .byte 0\n"   /* type */
 ".previous\n"
 ".section .altinstr_replacement,\"ax\"\n"
 "4: jmp %l[t_no]\n"
@@ -169,6 +170,7 @@ static __always_inline __pure bool _stat
 " .byte 3b - 1b\n" /* src len */
 " .byte 0\n"   /* repl len */
 " .byte 0\n"   /* pad len */
+" .byte 0\n"   /* type */
 ".previous\n"
 ".section .altinstr_aux,\"ax\"\n"
 "6:\n"
--- a/tools/objtool/special.c
+++ b/tools/objtool/special.c
@@ -34,7 +34,7 @@
 #define JUMP_ORIG_OFFSET   0
 #define JUMP_NEW_OFFSET8
 
-#define ALT_ENTRY_SIZE 13
+#define ALT_ENTRY_SIZE 14
 #define ALT_ORIG_OFFSET0
 #define ALT_NEW_OFFSET 4
 #define ALT_FEATURE_OFFSET 8

Re: [PATCH net-next v5 0/4] net: mvpp2: 1000BaseX and 2500BaseX support

[Antoine Tenart]

Hi Russell,

On Tue, Jan 16, 2018 at 03:12:45PM +, Russell King - ARM Linux wrote:
> 
> As I've already said, we need to make sure things are done in a similar
> way for all netdev DT drivers that are hoping to switch to phylink.
> The mvneta patches are now in net-next for this.
> 
> What I can see is that there's a stark difference between mvpp2 and
> mvneta and their handling of the "link irq" aka inband autonegotiation
> status.
> 
> mvneta requires 'managed = "in-band-status";' to use the results of
> the gmac negotiation otherwise inband AN is disabled.  As phylink was
> developed against mvneta, phylink requires that for Base-X modes.
> 
> So, in order to be compatible with mvneta and to do what phylink expects,
> specifying 'managed = "in-band-status";' is a requirement for Base-X
> modes, and having that in place _now_ will make the transition to
> phylink easier without creating the need to update DT when that change
> happens.

Yes, we should aim for similar bindings and not having all drivers doing
their own way. Part of the PPv2 move to phylink will be to rework the
"link irq" to match what phylink expect, and I think we all agree on
this. Part of this will be to update the dt of the 7k-db and 8k-db, as
they're the two boards currently using the "link irq" in mainline.

I don't mind too much keeping these base-X patches out-of-tree for now,
and to send them as part of the phylink series during the next cycle.

I don't quite get the reason not to take them now, as they do not
modify any DT-related part. Or do you fear this would allow others to
send DT patches before the PPv2 move to phylink lands in?

Thanks,
Antoine

-- 
Antoine Ténart, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

[PATCH-next] MEMCG: memcontrol: make local symbol static

[Christopher Díaz Riveros]

Fixes the following sparse warning:

mm/memcontrol.c:1097:14: warning:
  symbol 'memcg1_stats' was not declared. Should it be static?

Signed-off-by: Christopher Díaz Riveros 
---
 mm/memcontrol.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index c3d1eaef752d..396674fd97ef 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -1094,7 +1094,7 @@ static bool mem_cgroup_wait_acct_move(struct mem_cgroup 
*memcg)
return false;
 }
 
-unsigned int memcg1_stats[] = {
+static unsigned int memcg1_stats[] = {
MEMCG_CACHE,
MEMCG_RSS,
MEMCG_RSS_HUGE,
-- 
2.15.1

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

[Florian Fainelli]

On January 17, 2018 11:31:23 PM PST, Christoph Hellwig  wrote:
>On Wed, Jan 17, 2018 at 08:15:33PM -0600, Rob Herring wrote:
>> > (a) overriding/redefining the dma_to_phys() and phys_to_dma() calls
>> > that are used by the dma_ops routines.  This is the approach of
>> >
>> > arch/mips/cavium-octeon/dma-octeon.c
>> 
>> MIPS is rarely an example to follow. :)
>
>But in this case it actually is the example to follow as told
>previously.
>
>NAK again for these chained dma ops that only create problems.

Care to explain what should be done instead?

-- 
Florian

Re: [PATCH-next] MEMCG: memcontrol: make local symbol static

[Joe Perches]

On Thu, 2018-01-18 at 10:08 -0500, Christopher Díaz Riveros wrote:
> Fixes the following sparse warning:
> 
> mm/memcontrol.c:1097:14: warning:
>   symbol 'memcg1_stats' was not declared. Should it be static?
> 
> Signed-off-by: Christopher Díaz Riveros 
> ---
>  mm/memcontrol.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
[]
> @@ -1094,7 +1094,7 @@ static bool mem_cgroup_wait_acct_move(struct mem_cgroup 
> *memcg)
>   return false;
>  }
>  
> -unsigned int memcg1_stats[] = {
> +static unsigned int memcg1_stats[] = {

This should almost certainly be static const

>   MEMCG_CACHE,
>   MEMCG_RSS,
>   MEMCG_RSS_HUGE,

Re: [PATCH v5 1/2] printk: Add console owner and waiter logic to load balance console writes

[Steven Rostedt]

On Thu, 18 Jan 2018 13:01:46 +0900
Byungchul Park  wrote:

> > I disagree. It is like a spinlock. You can say a spinlock() that is
> > blocked is also waiting for an event. That event being the owner does a
> > spin_unlock().  
> 
> That's exactly what I was saying. Excuse me but, I don't understand
> what you want to say. Could you explain more? What do you disagree?

I guess I'm confused at what you are asking for then.


> > I find your way confusing. I'm simulating a spinlock not a wait for
> > completion. A wait for completion usually initiates something then  
> 
> I used the word, *event* instead of *completion*. wait_for_completion()
> and complete() are just an example of a pair of waiter and event.
> Lock and unlock can also be another example, too.
> 
> Important thing is that who waits and who triggers the event. Using the
> pair, we can achieve various things, for examples:
> 
> 1. Synchronization like wait_for_completion() does.
> 2. Control exclusively entering into a critical area.
> 3. Whatever.
> 
> > waits for it to complete. This is trying to get into a critical area
> > but another task is currently in it. It's simulating a spinlock as far
> > as I can see.  
> 
> Anyway it's an example of "waiter for an event, and the event".
> 
> JFYI, spinning or sleeping does not matter. Those are just methods to
> achieve a wait. I know you're not talking about this though. It's JFYI.

OK, if it is just FYI.

-- Steve

[net-next: PATCH v4 3/7] device property: Introduce fwnode_irq_get()

[Marcin Wojtas]

Until now there were two very similar functions allowing
to get Linux IRQ number from ACPI handle (acpi_irq_get())
and OF node (of_irq_get()). The first one appeared to be used
only as a subroutine of platform_irq_get(), which (in the generic
code) limited IRQ obtaining from _CRS method only to nodes
associated to kernel's struct platform_device.

This patch introduces a new helper routine - fwnode_irq_get(),
which allows to get the IRQ number directly from the fwnode
to be used as common for OF/ACPI worlds. It is usable not
only for the parents fwnodes, but also for the child nodes
comprising their own _CRS methods with interrupts description.

In order to be able o satisfy compilation with !CONFIG_ACPI
and also simplify the new code, introduce a helper macro
(ACPI_HANDLE_FWNODE), with which it is possible to reach
an ACPI handle directly from its fwnode.

Signed-off-by: Marcin Wojtas 
---
 drivers/base/property.c  | 26 
 include/linux/acpi.h |  3 +++
 include/linux/property.h |  2 ++
 3 files changed, 31 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 7c4a53d..1d6c9d9 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1230,6 +1231,31 @@ void *device_get_mac_address(struct device *dev, char 
*addr, int alen)
 EXPORT_SYMBOL(device_get_mac_address);
 
 /**
+ * fwnode_irq_get - Get IRQ directly from a fwnode
+ * @fwnode:Pointer to the firmware node
+ * @index: Zero-based index of the IRQ
+ *
+ * Returns Linux IRQ number on success. Other values are determined
+ * accordingly to acpi_/of_ irq_get() operation.
+ */
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index)
+{
+   struct device_node *of_node = to_of_node(fwnode);
+   struct resource res;
+   int ret;
+
+   if (IS_ENABLED(CONFIG_OF) && of_node)
+   return of_irq_get(of_node, index);
+
+   ret = acpi_irq_get(ACPI_HANDLE_FWNODE(fwnode), index, );
+   if (ret)
+   return ret;
+
+   return res.start;
+}
+EXPORT_SYMBOL(fwnode_irq_get);
+
+/**
  * device_graph_get_next_endpoint - Get next endpoint firmware node
  * @fwnode: Pointer to the parent firmware node
  * @prev: Previous endpoint node or %NULL to get the first
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index dc1ebfe..f05b9b6 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,8 @@ static inline acpi_handle acpi_device_handle(struct 
acpi_device *adev)
 #define ACPI_COMPANION_SET(dev, adev)  set_primary_fwnode(dev, (adev) ? \
acpi_fwnode_handle(adev) : NULL)
 #define ACPI_HANDLE(dev)   acpi_device_handle(ACPI_COMPANION(dev))
+#define ACPI_HANDLE_FWNODE(fwnode) \
+   acpi_device_handle(to_acpi_device_node(fwnode))
 
 static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
 {
@@ -626,6 +628,7 @@ int acpi_arch_timer_mem_init(struct arch_timer_mem 
*timer_mem, int *timer_count)
 #define ACPI_COMPANION(dev)(NULL)
 #define ACPI_COMPANION_SET(dev, adev)  do { } while (0)
 #define ACPI_HANDLE(dev)   (NULL)
+#define ACPI_HANDLE_FWNODE(fwnode) (NULL)
 #define ACPI_DEVICE_CLASS(_cls, _msk)  .cls = (0), .cls_msk = (0),
 
 struct fwnode_handle;
diff --git a/include/linux/property.h b/include/linux/property.h
index 9b13332..e05889f 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -103,6 +103,8 @@ struct fwnode_handle *device_get_named_child_node(struct 
device *dev,
 struct fwnode_handle *fwnode_handle_get(struct fwnode_handle *fwnode);
 void fwnode_handle_put(struct fwnode_handle *fwnode);
 
+int fwnode_irq_get(struct fwnode_handle *fwnode, unsigned int index);
+
 unsigned int device_get_child_node_count(struct device *dev);
 
 static inline bool device_property_read_bool(struct device *dev,
-- 
2.7.4

[net-next: PATCH v4 6/7] net: mvpp2: use device_*/fwnode_* APIs instead of of_*

[Marcin Wojtas]

OF functions can be used only for the driver using DT.
As a preparation for introducing ACPI support in mvpp2
driver, use struct fwnode_handle in order to obtain
properties from the hardware description.

This patch replaces of_* function with device_*/fwnode_*
where possible in the mvpp2.

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2.c | 45 +++-
 1 file changed, 24 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index 7f42d90..f16448e 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -932,6 +932,9 @@ struct mvpp2_port {
 
struct mvpp2 *priv;
 
+   /* Firmware node associated to the port */
+   struct fwnode_handle *fwnode;
+
/* Per-port registers' base address */
void __iomem *base;
void __iomem *stats_base;
@@ -7711,17 +7714,16 @@ static bool mvpp2_port_has_tx_irqs(struct mvpp2 *priv,
 }
 
 static void mvpp2_port_copy_mac_addr(struct net_device *dev, struct mvpp2 
*priv,
-struct device_node *port_node,
+struct fwnode_handle *fwnode,
 char **mac_from)
 {
struct mvpp2_port *port = netdev_priv(dev);
char hw_mac_addr[ETH_ALEN] = {0};
-   const char *dt_mac_addr;
+   char fw_mac_addr[ETH_ALEN];
 
-   dt_mac_addr = of_get_mac_address(port_node);
-   if (dt_mac_addr && is_valid_ether_addr(dt_mac_addr)) {
-   *mac_from = "device tree";
-   ether_addr_copy(dev->dev_addr, dt_mac_addr);
+   if (fwnode_get_mac_address(fwnode, fw_mac_addr, ETH_ALEN)) {
+   *mac_from = "firmware node";
+   ether_addr_copy(dev->dev_addr, fw_mac_addr);
return;
}
 
@@ -7740,13 +7742,14 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
-   struct device_node *port_node,
+   struct fwnode_handle *port_fwnode,
struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
struct mvpp2_port *port;
struct mvpp2_port_pcpu *port_pcpu;
+   struct device_node *port_node = to_of_node(port_fwnode);
struct net_device *dev;
struct resource *res;
char *mac_from = "";
@@ -7773,7 +7776,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
return -ENOMEM;
 
phy_node = of_parse_phandle(port_node, "phy", 0);
-   phy_mode = of_get_phy_mode(port_node);
+   phy_mode = fwnode_get_phy_mode(port_fwnode);
if (phy_mode < 0) {
dev_err(>dev, "incorrect phy mode\n");
err = phy_mode;
@@ -7789,7 +7792,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
comphy = NULL;
}
 
-   if (of_property_read_u32(port_node, "port-id", )) {
+   if (fwnode_property_read_u32(port_fwnode, "port-id", )) {
err = -EINVAL;
dev_err(>dev, "missing port-id value\n");
goto err_free_netdev;
@@ -7820,7 +7823,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
/* the link irq is optional */
port->link_irq = 0;
 
-   if (of_property_read_bool(port_node, "marvell,loopback"))
+   if (fwnode_property_read_bool(port_fwnode, "marvell,loopback"))
port->flags |= MVPP2_F_LOOPBACK;
 
port->id = id;
@@ -7845,8 +7848,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
   MVPP21_MIB_COUNTERS_OFFSET +
   port->gop_id * MVPP21_MIB_COUNTERS_PORT_SZ;
} else {
-   if (of_property_read_u32(port_node, "gop-port-id",
->gop_id)) {
+   if (fwnode_property_read_u32(port_fwnode, "gop-port-id",
+>gop_id)) {
err = -EINVAL;
dev_err(>dev, "missing gop-port-id value\n");
goto err_deinit_qvecs;
@@ -7876,7 +7879,7 @@ static int mvpp2_port_probe(struct platform_device *pdev,
mutex_init(>gather_stats_lock);
INIT_DELAYED_WORK(>stats_work, mvpp2_gather_hw_statistics);
 
-   mvpp2_port_copy_mac_addr(dev, priv, port_node, _from);
+   mvpp2_port_copy_mac_addr(dev, priv, port_fwnode, _from);
 
port->tx_ring_size = MVPP2_MAX_TXD_DFLT;
port->rx_ring_size = MVPP2_MAX_RXD_DFLT;
@@ -8194,8 +8197,8 @@ static int mvpp2_init(struct platform_device *pdev, 
struct mvpp2 *priv)
 
 static int mvpp2_probe(struct platform_device *pdev)
 {
-   struct device_node *dn = pdev->dev.of_node;
-   struct device_node 

[net-next: PATCH v4 4/7] device property: Allow iterating over available child fwnodes

[Marcin Wojtas]

Implement a new helper function fwnode_get_next_available_child_node(),
which enables obtaining next enabled child fwnode, which
works on a similar basis to OF's of_get_next_available_child().

This commit also introduces a macro, thanks to which it is
possible to iterate over the available fwnodes, using the
new function described above.

Signed-off-by: Marcin Wojtas 
---
 drivers/base/property.c  | 26 
 include/linux/property.h |  6 +
 2 files changed, 32 insertions(+)

diff --git a/drivers/base/property.c b/drivers/base/property.c
index 1d6c9d9..613ba82 100644
--- a/drivers/base/property.c
+++ b/drivers/base/property.c
@@ -998,6 +998,32 @@ fwnode_get_next_child_node(const struct fwnode_handle 
*fwnode,
 EXPORT_SYMBOL_GPL(fwnode_get_next_child_node);
 
 /**
+ * fwnode_get_next_available_child_node - Return the next
+ * available child node handle for a node
+ * @fwnode: Firmware node to find the next child node for.
+ * @child: Handle to one of the node's child nodes or a %NULL handle.
+ */
+struct fwnode_handle *
+fwnode_get_next_available_child_node(const struct fwnode_handle *fwnode,
+struct fwnode_handle *child)
+{
+   struct fwnode_handle *next_child = child;
+
+   if (!fwnode)
+   return NULL;
+
+   do {
+   next_child = fwnode_get_next_child_node(fwnode, next_child);
+
+   if (!next_child || fwnode_device_is_available(next_child))
+   break;
+   } while (next_child);
+
+   return next_child;
+}
+EXPORT_SYMBOL_GPL(fwnode_get_next_available_child_node);
+
+/**
  * device_get_next_child_node - Return the next child node handle for a device
  * @dev: Device to find the next child node for.
  * @child: Handle to one of the device's child nodes or a null handle.
diff --git a/include/linux/property.h b/include/linux/property.h
index e05889f..5b0563a 100644
--- a/include/linux/property.h
+++ b/include/linux/property.h
@@ -83,11 +83,17 @@ struct fwnode_handle *fwnode_get_next_parent(
struct fwnode_handle *fwnode);
 struct fwnode_handle *fwnode_get_next_child_node(
const struct fwnode_handle *fwnode, struct fwnode_handle *child);
+struct fwnode_handle *fwnode_get_next_available_child_node(
+   const struct fwnode_handle *fwnode, struct fwnode_handle *child);
 
 #define fwnode_for_each_child_node(fwnode, child)  \
for (child = fwnode_get_next_child_node(fwnode, NULL); child;   \
 child = fwnode_get_next_child_node(fwnode, child))
 
+#define fwnode_for_each_available_child_node(fwnode, child)   \
+   for (child = fwnode_get_next_available_child_node(fwnode, NULL); child;\
+child = fwnode_get_next_available_child_node(fwnode, child))
+
 struct fwnode_handle *device_get_next_child_node(
struct device *dev, struct fwnode_handle *child);
 
-- 
2.7.4

[net-next: PATCH v4 0/7] Armada 7k/8k PP2 ACPI support

[Marcin Wojtas]

Hi,

I quickly resend the series, thanks to Antoine Tenart's remark,
who spotted !CONFIG_ACPI compilation issue after introducing
the new fwnode_irq_get() routine. Please see the details in the changelog
below and the 3/7 commit log.

mvpp2 driver can work with the ACPI representation, as exposed
on a public branch:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/marvell-armada-wip
It was compiled together with the most recent Tianocore EDK2 revision.
Please refer to the firmware build instruction on MacchiatoBin board:
http://wiki.macchiatobin.net/tiki-index.php?page=Build+from+source+-+UEFI+EDK+II

ACPI representation of PP2 controllers (withouth PHY support) can
be viewed in the github:
* MacchiatoBin:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada80x0McBin/Dsdt.asl#L201

* Armada 7040 DB:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/blob/71ae395da1661374b0f07d1602afb1eee56e9794/Platforms/Marvell/Armada/AcpiTables/Armada70x0/Dsdt.asl#L131

I will appreciate any comments or remarks.

Best regards,
Marcin

Changelog:
v3 -> v4:
* 3/7
- add new macro (ACPI_HANDLE_FWNODE) and fix
  compilation with !CONFIG_ACPI
- extend commit log and mention usability of fwnode_irq_get
  for the child nodes as well

v2 -> v3:
* 1/7, 2/7
- Add Rafael's Acked-by's
* 3/7, 4/7
- New patches
* 6/7, 7/7
- Update driver with new helper routines usage
- Improve commit log.

v1 -> v2:
* Remove MDIO patches
* Use PP2 ports only with link interrupts
* Release second region resources in mvpp2 driver (code moved from
  mvmdio), as explained in details in 5/5 commit message.

Marcin Wojtas (7):
  device property: Introduce fwnode_get_mac_address()
  device property: Introduce fwnode_get_phy_mode()
  device property: Introduce fwnode_irq_get()
  device property: Allow iterating over available child fwnodes
  net: mvpp2: simplify maintaining enabled ports' list
  net: mvpp2: use device_*/fwnode_* APIs instead of of_*
  net: mvpp2: enable ACPI support in the driver

 drivers/base/property.c  | 104 --
 drivers/net/ethernet/marvell/mvpp2.c | 206 
 include/linux/acpi.h |   3 +
 include/linux/property.h |  11 ++
 4 files changed, 232 insertions(+), 92 deletions(-)

-- 
2.7.4

[net-next: PATCH v4 5/7] net: mvpp2: simplify maintaining enabled ports' list

[Marcin Wojtas]

'port_count' field of the mvpp2 structure holds an overall amount
of available ports, based on DT nodes status. In order to be prepared
to support other HW description, obtain the value by incrementing it
upon each successful port initialization. This allowed for simplifying
port indexing in the controller's private array, whose size is now not
dynamically allocated, but fixed to MVPP2_MAX_PORTS.

This patch simplifies creating and filling list of enabled ports and
is a part of the preparation for adding ACPI support in the mvpp2 driver.

Signed-off-by: Marcin Wojtas 
---
 drivers/net/ethernet/marvell/mvpp2.c | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2.c 
b/drivers/net/ethernet/marvell/mvpp2.c
index a197607..7f42d90 100644
--- a/drivers/net/ethernet/marvell/mvpp2.c
+++ b/drivers/net/ethernet/marvell/mvpp2.c
@@ -865,7 +865,7 @@ struct mvpp2 {
 
/* List of pointers to port structures */
int port_count;
-   struct mvpp2_port **port_list;
+   struct mvpp2_port *port_list[MVPP2_MAX_PORTS];
 
/* Aggregated TXQs */
struct mvpp2_tx_queue *aggr_txqs;
@@ -7741,7 +7741,7 @@ static void mvpp2_port_copy_mac_addr(struct net_device 
*dev, struct mvpp2 *priv,
 /* Ports initialization */
 static int mvpp2_port_probe(struct platform_device *pdev,
struct device_node *port_node,
-   struct mvpp2 *priv, int index)
+   struct mvpp2 *priv)
 {
struct device_node *phy_node;
struct phy *comphy;
@@ -7934,7 +7934,8 @@ static int mvpp2_port_probe(struct platform_device *pdev,
}
netdev_info(dev, "Using %s mac address %pM\n", mac_from, dev->dev_addr);
 
-   priv->port_list[index] = port;
+   priv->port_list[priv->port_count++] = port;
+
return 0;
 
 err_free_port_pcpu:
@@ -8313,28 +8314,17 @@ static int mvpp2_probe(struct platform_device *pdev)
goto err_mg_clk;
}
 
-   priv->port_count = of_get_available_child_count(dn);
-   if (priv->port_count == 0) {
-   dev_err(>dev, "no ports enabled\n");
-   err = -ENODEV;
-   goto err_mg_clk;
-   }
-
-   priv->port_list = devm_kcalloc(>dev, priv->port_count,
-  sizeof(*priv->port_list),
-  GFP_KERNEL);
-   if (!priv->port_list) {
-   err = -ENOMEM;
-   goto err_mg_clk;
-   }
-
/* Initialize ports */
-   i = 0;
for_each_available_child_of_node(dn, port_node) {
-   err = mvpp2_port_probe(pdev, port_node, priv, i);
+   err = mvpp2_port_probe(pdev, port_node, priv);
if (err < 0)
goto err_port_probe;
-   i++;
+   }
+
+   if (priv->port_count == 0) {
+   dev_err(>dev, "no ports enabled\n");
+   err = -ENODEV;
+   goto err_mg_clk;
}
 
/* Statistics must be gathered regularly because some of them (like
-- 
2.7.4

Re: [PATCH v4 11/13] iommu/rockchip: Fix error handling in init

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

It's hard to undo bus_set_iommu() in the error path, so move it to the
end of rk_iommu_probe().


Reviewed-by: Robin Murphy 


Signed-off-by: Jeffy Chen 
Reviewed-by: Tomasz Figa 
---

Changes in v4: None
Changes in v3: None
Changes in v2:
Move bus_set_iommu() to rk_iommu_probe().

  drivers/iommu/rockchip-iommu.c | 15 ++-
  1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index b1f177ae03c7..2c095f96c033 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -1195,6 +1195,8 @@ static int rk_iommu_probe(struct platform_device *pdev)
if (!dma_dev)
dma_dev = >dev;
  
+	bus_set_iommu(_bus_type, _iommu_ops);

+
return 0;
  err_remove_sysfs:
iommu_device_sysfs_remove(>iommu);
@@ -1220,19 +1222,6 @@ static struct platform_driver rk_iommu_driver = {
  
  static int __init rk_iommu_init(void)

  {
-   struct device_node *np;
-   int ret;
-
-   np = of_find_matching_node(NULL, rk_iommu_dt_ids);
-   if (!np)
-   return 0;
-
-   of_node_put(np);
-
-   ret = bus_set_iommu(_bus_type, _iommu_ops);
-   if (ret)
-   return ret;
-
return platform_driver_register(_iommu_driver);
  }
  subsys_initcall(rk_iommu_init);

Re: [PATCH v5 21/44] clk: davinci: New driver for TI DA8XX USB PHY clocks

[Sekhar Nori]

On Monday 08 January 2018 07:47 AM, David Lechner wrote:

> +static int da8xx_usb1_phy_clk_set_parent(struct clk_hw *hw, u8 index)
> +{
> + struct da8xx_usb1_phy_clk *clk = to_da8xx_usb1_phy_clk(hw);
> + unsigned int mask, val;
> +
> + /* Set the USB 1.1 PHY clock mux based on the parent clock. */
> + mask = CFGCHIP2_USB1PHYCLKMUX;
> + switch (index) {
> + case DA8XX_USB1_PHY_CLK_PARENT_USB_REFCLKIN:
> + val = CFGCHIP2_USB1PHYCLKMUX;
> + break;
> + case DA8XX_USB1_PHY_CLK_PARENT_USB0_PHY_PLL:
> + val = 0;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + regmap_write_bits(clk->regmap, CFGCHIP(2), mask, val);

This function can be simplified quite a bit if you use a shift.

#define CFGCHIP2_USB1PHYCLKMUX_SHIFT12

static int da8xx_usb1_phy_clk_set_parent(struct clk_hw *hw, u8 index)
{
struct da8xx_usb1_phy_clk *clk = to_da8xx_usb1_phy_clk(hw);

regmap_write_bits(clk->regmap, CFGCHIP(2),
  CFGCHIP2_USB1PHYCLKMUX,
  index << CFGCHIP2_USB1PHYCLKMUX_SHIFT);
}

Same thing for da8xx_usb0_phy_clk_set_parent() as well.

Thanks,
Sekhar

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Dmitry Vyukov]

On Thu, Jan 18, 2018 at 2:01 PM, Dmitry Vyukov  wrote:
> On Thu, Jan 18, 2018 at 2:09 AM, Theodore Ts'o  wrote:
>> On Wed, Jan 17, 2018 at 04:21:13PM -0800, Alexei Starovoitov wrote:
>>>
>>> If syzkaller can only test one tree than linux-next should be the one.
>>
>> Well, there's been some controversy about that.  The problem is that
>> it's often not clear if this is long-standing bug, or a bug which is
>> in a particular subsystem tree --- and if so, *which* subsystem tree,
>> etc.  So it gets blasted to linux-kernel, and to get_maintainer.pl,
>> which is often not accurate --- since the location of the crash
>> doesn't necessarily point out where the problem originated, and hence
>> who should look at the syzbot report.  And so this has caused
>> some irritation.
>
>
> Re set of tested trees.
>
> We now have an interesting spectrum of opinions.
>
> Some assorted thoughts on this:
>
> 1. First, "upstream is clean" won't happen any time soon. There are
> several reasons for this:
>  - Currently syzkaller only tests a subset of subsystems that it knows
> how to test, even the ones that it tests it tests poorly. Over time
> it's improved to test most subsystems and existing subsystems better.
> Just few weeks ago I've added some descriptions for crypto subsystem
> and it uncovered 20+ old bugs.

/\/\/\/\/\/\/\/\/\/\/\/\

While we are here, you can help syzkaller to test your subsystem
better (or at all). It frequently requires domain expertise which we
don't have for all kernel subsystems (sometimes we don't even know
they exist). It can be as simple as this (for /dev/ashmem):
https://github.com/google/syzkaller/blob/master/sys/linux/ashmem.txt


>  - syzkaller is guided, genetic fuzzer over time it leans how to do
> more complex things by small steps. It takes time.
>  - We have more bug detection tools coming: LEAKCHECK, KMSAN (uninit
> memory), KTSAN (data races).
>  - generic syzkaller smartness will be improved over time.
>  - it will get more CPU resources.
> Effect of all of these things is multiplicative: we test more code,
> smarter, with more bug-detection tools, with more resources. So I
> think we need to plan for a mix of old and new bugs for foreseeable
> future.
>
> 2. get_maintainer.pl and mix of old and new bugs was mentioned as
> harming attribution. I don't see what will change when/if we test only
> upstream. Then the same mix of old/new bugs will be detected just on
> upstream, with all of the same problems for old/new, maintainers,
> which subsystem, etc. I think the amount of bugs in the kernel is
> significant part of the problem, but the exact boundary where we
> decide to start killing them won't affect number of bugs.
>
> 3. If we test only upstream, we increase chances of new security bugs
> sinking into releases. We sure could raise perceived security value of
> the bugs by keeping them private, letting them sink into release,
> letting them sink into distros, and then reporting a high-profile
> vulnerability. I think that's wrong. There is something broken with
> value measuring in security community. Bug that is killed before
> sinking into any release is the highest impact thing. As Alexei noted,
> fixing bugs es early as possible also reduces fix costs, backporting
> burden, etc. This also can eliminate need in bisection in some cases,
> say if you accepted a large change to some files and a bunch of
> crashes appears for these files on your tree soon, it's obvious what
> happens.
>
> 4. It was mentioned that linux-next can have a broken slab allocator
> and that will manifest as multiple random crashes. FWIW I don't
> remember that I ever seen this. Yes, sometimes it does not build/boot,
> but these builds are just rejected for testing.
>
> I don't mind dropping linux-next specifically if that's the common
> decision. However, (1) Alexei and Gruenter expressed opposite opinion,
> (2) I don't see what it will change dramatically, (2) as far as I
> understand Linus actually relies on linux-next giving some concrete
> testing to the code there.
> But I think that testing bpf-next is a positive thing provided that
> there is explicit interest from maintainers. And note that that will
> be testing targeted specifically at bpf subsystem, so that instance
> will not generate bugs in SCSI, USB, etc (though it will cover a part
> of net). Also note that the latest email format includes set of tree
> where the crash happened, so if you see "upstream" or "upstream and
> bpf-next", nothing really changes, you still know that it happens
> upstream. Or if you see only "bpf-next", then you know that it's only
> that tree.

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Dmitry Vyukov]

On Wed, Jan 17, 2018 at 12:09 PM, Dmitry Vyukov  wrote:
> On Wed, Jan 17, 2018 at 10:49 AM, Daniel Borkmann  
> wrote:
>> Don't know if there's such a possibility, but it would be nice if we could
>> target fuzzing for specific subsystems in related subtrees directly (e.g.
>> for bpf in bpf and bpf-next trees as one example). Dmitry?
>
> Hi Daniel,
>
> It's doable.
> Let's start with one bpf tree. Will it be bpf or bpf-next? Which one
> contains more ongoing work? What's the exact git repo address/branch,
> so that I don't second guess?
> Also what syscalls it makes sense to enable there to target it at bpf
> specifically? As far as I understand effects of bpf are far beyond the
> bpf call and proper testing requires some sockets and other stuff. For
> sockets, will it be enough to enable ip/ipv6? Because if we enable all
> of sctp/dccp/tipc/pptp/etc, it will sure will be finding lots of bugs
> there as well. Does bpf affect incoming network packets?
> Also are there any sysctl's, command line arguments, etc that need to
> be tuned. I know there are net.core.bpf_jit_enable/harden, but I don't
> know what's the most relevant combination. Ideally, we test all of
> them, but let start with one of them because it requires separate
> instances (since the setting is global and test programs can't just
> flip it randomly).
> Also do you want testing from root or not from root? We generally
> don't test under root, because syzkaller comes up with legal ways to
> shut everything down even if we try to contain it (e.g. kill init
> somehow or shut down network using netlink). But if we limit syscall
> surface, then root may work and allow testing staging bpf features.

So, Daniel, Alexei,

I understand that I asked lots of questions, but they are relatively
simple. I need that info to setup proper testing.

Re: [PATCH v4 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

From: Tomasz Figa 

This patch converts the rockchip-iommu driver to use the in-kernel
iopoll helpers to wait for certain status bits to change in registers
instead of an open-coded custom macro.

Signed-off-by: Tomasz Figa 
Signed-off-by: Jeffy Chen 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  drivers/iommu/rockchip-iommu.c | 68 --
  1 file changed, 32 insertions(+), 36 deletions(-)

diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 37065a7127c9..4a1c710408af 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -13,7 +13,7 @@
  #include 
  #include 
  #include 
-#include 
+#include 
  #include 
  #include 
  #include 
@@ -36,7 +36,8 @@
  #define RK_MMU_AUTO_GATING0x24
  
  #define DTE_ADDR_DUMMY		0xCAFEBABE

-#define FORCE_RESET_TIMEOUT100 /* ms */
+#define FORCE_RESET_TIMEOUT10  /* us */
+#define POLL_TIMEOUT   1000/* us */


Nit: the callsites look a bit odd with the combination of POLL_TIMEOUT 
and the magic number 100 - should we not also define something like 
POLL_PERIOD for that? Also POLL_TIMEOUT is a rather generic name and 
overlaps with several other drivers, so a namespace prefix would be 
helpful (i.e. RK_IOMMU_POLL*, or at least RK_POLL*).


FWIW, my personal preference would be to also suffix these with _US for 
absolute clarity, but it's not essential (especially if longer names 
lead to more linebreaks at the callsites).


With those undocumented "100"s fixed up,

Reviewed-by: Robin Murphy 


  /* RK_MMU_STATUS fields */
  #define RK_MMU_STATUS_PAGING_ENABLED   BIT(0)
@@ -73,8 +74,6 @@
*/
  #define RK_IOMMU_PGSIZE_BITMAP 0x007ff000
  
-#define IOMMU_REG_POLL_COUNT_FAST 1000

-
  struct rk_iommu_domain {
struct list_head iommus;
struct platform_device *pdev;
@@ -109,27 +108,6 @@ static struct rk_iommu_domain *to_rk_domain(struct 
iommu_domain *dom)
return container_of(dom, struct rk_iommu_domain, domain);
  }
  
-/**

- * Inspired by _wait_for in intel_drv.h
- * This is NOT safe for use in interrupt context.
- *
- * Note that it's important that we check the condition again after having
- * timed out, since the timeout could be due to preemption or similar and
- * we've never had a chance to check the condition before the timeout.
- */
-#define rk_wait_for(COND, MS) ({ \
-   unsigned long timeout__ = jiffies + msecs_to_jiffies(MS) + 1;   \
-   int ret__ = 0;  \
-   while (!(COND)) {   \
-   if (time_after(jiffies, timeout__)) {   \
-   ret__ = (COND) ? 0 : -ETIMEDOUT;\
-   break;  \
-   }   \
-   usleep_range(50, 100);  \
-   }   \
-   ret__;  \
-})
-
  /*
   * The Rockchip rk3288 iommu uses a 2-level page table.
   * The first level is the "Directory Table" (DT).
@@ -333,9 +311,21 @@ static bool rk_iommu_is_paging_enabled(struct rk_iommu 
*iommu)
return enable;
  }
  
+static bool rk_iommu_is_reset_done(struct rk_iommu *iommu)

+{
+   bool done = true;
+   int i;
+
+   for (i = 0; i < iommu->num_mmu; i++)
+   done &= rk_iommu_read(iommu->bases[i], RK_MMU_DTE_ADDR) == 0;
+
+   return done;
+}
+
  static int rk_iommu_enable_stall(struct rk_iommu *iommu)
  {
int ret, i;
+   bool val;
  
  	if (rk_iommu_is_stall_active(iommu))

return 0;
@@ -346,7 +336,8 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
  
  	rk_iommu_command(iommu, RK_MMU_CMD_ENABLE_STALL);
  
-	ret = rk_wait_for(rk_iommu_is_stall_active(iommu), 1);

+   ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
+val, 100, POLL_TIMEOUT);
if (ret)
for (i = 0; i < iommu->num_mmu; i++)
dev_err(iommu->dev, "Enable stall request timed out, status: 
%#08x\n",
@@ -358,13 +349,15 @@ static int rk_iommu_enable_stall(struct rk_iommu *iommu)
  static int rk_iommu_disable_stall(struct rk_iommu *iommu)
  {
int ret, i;
+   bool val;
  
  	if (!rk_iommu_is_stall_active(iommu))

return 0;
  
  	rk_iommu_command(iommu, RK_MMU_CMD_DISABLE_STALL);
  
-	ret = rk_wait_for(!rk_iommu_is_stall_active(iommu), 1);

+   ret = readx_poll_timeout(rk_iommu_is_stall_active, iommu, val,
+!val, 100, POLL_TIMEOUT);
if (ret)
for (i = 0; i < 

Re: [Patch v6 02/12] [media] s5p-mfc: Adding initial support for MFC v10.10

[Hans Verkuil]

On 01/18/18 13:36, Smitha T Murthy wrote:
> On Fri, 2017-12-08 at 14:25 +0100, Philippe Ombredanne wrote:
>> Smitha,
>>
>> On Fri, Dec 8, 2017 at 10:08 AM, Smitha T Murthy  
>> wrote:
>>> Adding the support for MFC v10.10, with new register file and
>>> necessary hw control, decoder, encoder and structural changes.
>>>
>>> CC: Rob Herring 
>>> CC: devicet...@vger.kernel.org
>>> Signed-off-by: Smitha T Murthy 
>>> Reviewed-by: Andrzej Hajda 
>>> Acked-by: Rob Herring 
>> []
>>> --- /dev/null
>>> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v10.h
>>> @@ -0,0 +1,36 @@
>>> +/*
>>> + * Register definition file for Samsung MFC V10.x Interface (FIMV) driver
>>> + *
>>> + * Copyright (c) 2017 Samsung Electronics Co., Ltd.
>>> + * http://www.samsung.com/
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>
>> Have you considered using the new SPDX ids instead of this fine legalese? 
>> e.g.:
>>
>> // SPDX-License-Identifier: GPL-2.0
>>
>> This is much shorter and neater (unless you are a legalese lover of
>> course!)  Check also Thomas doc patches and Linus comments on why he
>> prefers the C++ comment style for these.
>>
>> And even better could be this more compact form? I am a big fan of the
>> C++ style comments for these (and so is Linus)
>>
>> // SPDX-License-Identifier: GPL-2.0
>> // Copyright (c) 2017 Samsung Electronics Co., Ltd.
>> // Register definition file for Samsung MFC V10.x Interface (FIMV) driver
>>
>> You can also read this fine article from a fellow Samsung colleague
>> [1]. And if you ever consider doing this for all Samsung's past,
>> present and future contributions, you will have my deep gratitude
>>
>> [1] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/
>>
> Ok I will change to the SPDX license in the next patch series for the
> v10 register file. Correspondingly for the MFC driver's files I will
> update the license as a separate patch and submit.
> 

Ah, I forgot about this series. I'll try to review it tomorrow or Monday.

Sorry about the delay,

Hans

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

[Will Deacon]

Hi Dan, Linus,

On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote:
> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
>  wrote:
> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams  
> > wrote:
> >>
> >> This series incorporates Mark Rutland's latest ARM changes and adds
> >> the x86 specific implementation of 'ifence_array_ptr'. That ifence
> >> based approach is provided as an opt-in fallback, but the default
> >> mitigation, '__array_ptr', uses a 'mask' approach that removes
> >> conditional branches instructions, and otherwise aims to redirect
> >> speculation to use a NULL pointer rather than a user controlled value.
> >
> > Do you have any performance numbers and perhaps example code
> > generation? Is this noticeable? Are there any microbenchmarks showing
> > the difference between lfence use and the masking model?
> 
> I don't have performance numbers, but here's a sample code generation
> from __fcheck_files, where the 'and; lea; and' sequence is portion of
> array_ptr() after the mask generation with 'sbb'.
> 
> fdp = array_ptr(fdt->fd, fd, fdt->max_fds);
>  8e7:   8b 02   mov(%rdx),%eax
>  8e9:   48 39 c7cmp%rax,%rdi
>  8ec:   48 19 c9sbb%rcx,%rcx
>  8ef:   48 8b 42 08 mov0x8(%rdx),%rax
>  8f3:   48 89 femov%rdi,%rsi
>  8f6:   48 21 ceand%rcx,%rsi
>  8f9:   48 8d 04 f0 lea(%rax,%rsi,8),%rax
>  8fd:   48 21 c8and%rcx,%rax
> 
> 
> > Having both seems good for testing, but wouldn't we want to pick one in the 
> > end?
> 
> I was thinking we'd keep it as a 'just in case' sort of thing, at
> least until the 'probably safe' assumption of the 'mask' approach has
> more time to settle out.

>From the arm64 side, the only concern I have (and this actually applies to
our CSDB sequence as well) is the calculation of the array size by the
caller. As Linus mentioned at the end of [1], if the determination of the
size argument is based on a conditional branch, then masking doesn't help
because you bound within the wrong range under speculation.

We ran into this when trying to use masking to protect our uaccess routines
where the conditional bound is either KERNEL_DS or USER_DS. It's possible
that a prior conditional set_fs(KERNEL_DS) could defeat the masking and so
we'd need to throw some heavy barriers in set_fs to make it robust.

The question then is whether or not we're likely to run into this elsewhere,
and I don't have a good feel for that.

Will

[1] 
http://lkml.kernel.org/r/CA+55aFz0tsreoa=5ud2nofcpng-dizlbht9wu9asyhplfjd...@mail.gmail.com

[PATCH] media: i2c: ov7740: use gpio/consumer.h instead of gpio.h

[Arnd Bergmann]

When built on a platform without gpiolib support, we run into
a couple of compile errors in ov7740, including:

drivers/media/i2c/ov7740.c: In function 'ov7740_set_power':
drivers/media/i2c/ov7740.c:307:4: error: implicit declaration of function 
'gpiod_direction_output'; did you mean 'gpio_direction_output'? 
[-Werror=implicit-function-declaration]
gpiod_direction_output(ov7740->pwdn_gpio, 0);
drivers/media/i2c/ov7740.c:914:4: error: 'GPIOD_OUT_HIGH' undeclared (first use 
in this function); did you mean 'GPIOF_INIT_HIGH'?

Changing it to use the correct header file solves the problem.

Fixes: 39c5c4471b8d ("media: i2c: Add the ov7740 image sensor driver")
Signed-off-by: Arnd Bergmann 
---
 drivers/media/i2c/ov7740.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/i2c/ov7740.c b/drivers/media/i2c/ov7740.c
index 0308ba437bbb..0db107196d7a 100644
--- a/drivers/media/i2c/ov7740.c
+++ b/drivers/media/i2c/ov7740.c
@@ -3,7 +3,7 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.0

Re: [PATCH -next] mtd: ubi: wl: Fix error return code in ubi_wl_init()

[Boris Brezillon]

On Thu, 18 Jan 2018 14:05:05 +
Wei Yongjun <weiyongj...@huawei.com> wrote:

> Fix to return error code -ENOMEM from the kmem_cache_alloc() error
> handling case instead of 0, as done elsewhere in this function.

I guess you've used a static analysis code to detect this problem, can
you name it in the commit message, and paste the error/warning message
it reported next time you submit this kind of patch.

> 
> Signed-off-by: Wei Yongjun <weiyongj...@huawei.com>

NAck. I you read the code you'll see that err is initialized to -ENOMEM
here [1], so these changes are actually not needed.

> ---
>  drivers/mtd/ubi/wl.c | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
> index 77ab49f..2052a64 100644
> --- a/drivers/mtd/ubi/wl.c
> +++ b/drivers/mtd/ubi/wl.c
> @@ -1617,8 +1617,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
> ubi_attach_info *ai)
>   cond_resched();
>  
>   e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> - if (!e)
> + if (!e) {
> + err = -ENOMEM;
>   goto out_free;
> + }
>  
>   e->pnum = aeb->pnum;
>   e->ec = aeb->ec;
> @@ -1637,8 +1639,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
> ubi_attach_info *ai)
>   cond_resched();
>  
>   e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> - if (!e)
> + if (!e) {
> + err = -ENOMEM;
>   goto out_free;
> + }
>  
>   e->pnum = aeb->pnum;
>   e->ec = aeb->ec;
> 

[1]https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mtd/ubi/wl.c?h=next-20180118#n1596

Re: [PATCH v4 00/13] iommu/rockchip: Use OF_IOMMU

[JeffyChen]

Hi Joerg,

Thanks for your reply.

On 01/18/2018 08:44 PM, Joerg Roedel wrote:

On Thu, Jan 18, 2018 at 07:52:38PM +0800, Jeffy Chen wrote:

Jeffy Chen (9):
   iommu/rockchip: Prohibit unbind and remove
   iommu/rockchip: Fix error handling in probe
   iommu/rockchip: Request irqs in rk_iommu_probe()
   ARM: dts: rockchip: add clocks in vop iommu nodes
   iommu/rockchip: Use IOMMU device for dma mapping operations
   iommu/rockchip: Use OF_IOMMU to attach devices automatically
   iommu/rockchip: Fix error handling in init
   iommu/rockchip: Add runtime PM support
   iommu/rockchip: Support sharing IOMMU between masters

Tomasz Figa (4):
   iommu/rockchip: Fix error handling in attach
   iommu/rockchip: Use iopoll helpers to wait for hardware
   iommu/rockchip: Fix TLB flush of secondary IOMMUs
   iommu/rockchip: Control clocks needed to access the IOMMU


Please stop resending this every day with minimal changes. I am not
going to take it for v4.16, as we are late in the cycle already and there
are still review comments.

Just collect all feedback, update the patches, rebase them to v4.16-rc1
when its out, and send a new version.


oops, sorry, i send v4 today is mainly because i found v3 would break 
some of the rk platforms, which needs an extra patch [7] (ARM: dts: 
rockchip: add clocks in vop iommu nodes),  but forgot to mention it in 
the change log...


will send new version after all the rest patches been reviewed :)



Joerg

[PATCH v3 14/14] clk: stm32: Add clk entry for SDMMC2 on stm32F769

[patrice.chotard]

From: Patrice Chotard 

STM32F769 has 2 SDMMC port, add clock entry for the second one.

Signed-off-by: Alexandre TORGUE 
Signed-off-by: Patrice Chotard 
Acked-by: Stephen Boyd 
---

v3: _ none

v2: _ Add Acked-by


 drivers/clk/clk-stm32f4.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-stm32f4.c b/drivers/clk/clk-stm32f4.c
index da44f8d..e7e3965 100644
--- a/drivers/clk/clk-stm32f4.c
+++ b/drivers/clk/clk-stm32f4.c
@@ -282,6 +282,7 @@ struct stm32f4_gate_data {
 
{ STM32F4_RCC_APB2ENR,  0,  "tim1", "apb2_mul" },
{ STM32F4_RCC_APB2ENR,  1,  "tim8", "apb2_mul" },
+   { STM32F4_RCC_APB2ENR,  7,  "sdmmc2",   "sdmux"},
{ STM32F4_RCC_APB2ENR,  8,  "adc1", "apb2_div" },
{ STM32F4_RCC_APB2ENR,  9,  "adc2", "apb2_div" },
{ STM32F4_RCC_APB2ENR, 10,  "adc3", "apb2_div" },
@@ -315,7 +316,7 @@ struct stm32f4_gate_data {
 
 static const u64 stm32f746_gate_map[MAX_GATE_MAP] = { 0x00f17ef417ffull,
  0x0003ull,
- 0x04f77f033e01c9ffull };
+ 0x04f77f833e01c9ffull };
 
 static const u64 *stm32f4_gate_map;
 
-- 
1.9.1

[PATCH v3 02/14] mmc: mmci: Don't pretend all variants to have MCI_STARBITERR flag

[patrice.chotard]

From: Patrice Chotard 

This patch prepares for supporting the STM32 variant that
has no such bit in the status register.

Signed-off-by: Andrea Merello 
Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ replace start_err bool type by u32


 drivers/mmc/host/mmci.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 3125dc0..8a4fbc2 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -83,6 +83,8 @@
  * @qcom_dml: enables qcom specific dma glue for dma transfers.
  * @reversed_irq_handling: handle data irq before cmd irq.
  * @mmcimask1: true if variant have a MMCIMASK1 register.
+ * @start_err: bitmask identifying the STARTBITERR bit inside MMCISTATUS
+ *register.
  */
 struct variant_data {
unsigned intclkreg;
@@ -113,6 +115,7 @@ struct variant_data {
boolqcom_dml;
boolreversed_irq_handling;
boolmmcimask1;
+   u32 start_err;
 };
 
 static struct variant_data variant_arm = {
@@ -123,6 +126,7 @@ struct variant_data {
.f_max  = 1,
.reversed_irq_handling  = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_arm_extended_fifo = {
@@ -132,6 +136,7 @@ struct variant_data {
.pwrreg_powerup = MCI_PWR_UP,
.f_max  = 1,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_arm_extended_fifo_hwfc = {
@@ -142,6 +147,7 @@ struct variant_data {
.pwrreg_powerup = MCI_PWR_UP,
.f_max  = 1,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_u300 = {
@@ -158,6 +164,7 @@ struct variant_data {
.pwrreg_clkgate = true,
.pwrreg_nopower = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_nomadik = {
@@ -175,6 +182,7 @@ struct variant_data {
.pwrreg_clkgate = true,
.pwrreg_nopower = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_ux500 = {
@@ -198,6 +206,7 @@ struct variant_data {
.busy_detect_mask   = MCI_ST_BUSYENDMASK,
.pwrreg_nopower = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_ux500v2 = {
@@ -223,6 +232,7 @@ struct variant_data {
.busy_detect_mask   = MCI_ST_BUSYENDMASK,
.pwrreg_nopower = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 static struct variant_data variant_qcom = {
@@ -242,6 +252,7 @@ struct variant_data {
.qcom_fifo  = true,
.qcom_dml   = true,
.mmcimask1  = true,
+   .start_err  = MCI_STARTBITERR,
 };
 
 /* Busy detection for the ST Micro variant */
@@ -935,8 +946,9 @@ static void mmci_start_data(struct mmci_host *host, struct 
mmc_data *data)
return;
 
/* First check for errors */
-   if (status & (MCI_DATACRCFAIL|MCI_DATATIMEOUT|MCI_STARTBITERR|
- MCI_TXUNDERRUN|MCI_RXOVERRUN)) {
+   if (status & (MCI_DATACRCFAIL | MCI_DATATIMEOUT |
+ host->variant->start_err |
+ MCI_TXUNDERRUN | MCI_RXOVERRUN)) {
u32 remain, success;
 
/* Terminate the DMA transfer */
-- 
1.9.1

[PATCH v3 06/14] ARM: dts: stm32: Add SDIO controller for stm32f746

[patrice.chotard]

From: Patrice Chotard 

stm32f746 embeds ARM_PL180 sdio IP, adds SDIO controller
nodes to allow MMC support.

Signed-off-by: Patrice Chotard 
---

v3: _ none

v2: _ none

 arch/arm/boot/dts/stm32f746.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 5f66d15..7f55d00 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -429,6 +429,28 @@
status = "disabled";
};
 
+   sdio2: sdio2@40011c00 {
+   compatible = "arm,pl180", "arm,primecell";
+   arm,primecell-periphid = <0x00880180>;
+   reg = <0x40011c00 0x400>;
+   clocks = < 0 167>;
+   clock-names = "apb_pclk";
+   interrupts = <103>;
+   max-frequency = <4800>;
+   status = "disabled";
+   };
+
+   sdio1: sdio1@40012c00 {
+   compatible = "arm,pl180", "arm,primecell";
+   arm,primecell-periphid = <0x00880180>;
+   reg = <0x40012c00 0x400>;
+   clocks = < 0 171>;
+   clock-names = "apb_pclk";
+   interrupts = <49>;
+   max-frequency = <4800>;
+   status = "disabled";
+   };
+
syscfg: system-config@40013800 {
compatible = "syscon";
reg = <0x40013800 0x400>;
-- 
1.9.1

[PATCH v3 03/14] mmc: mmci: Don't pretend all variants to have OPENDRAIN bit

[patrice.chotard]

From: Patrice Chotard 

This patch prepares for supporting STM32 variant which doesn't
have opendrain bit in MMCIPOWER register.
ST others variant (u300, nomadik and ux500) uses MCI_OD bit whereas
others variants uses MCI_ROD bit.

Signed-off-by: Patrice Chotard 
---

v3: _ use variant->opendrain instead of host->variant->opendrain
_ remove comment about OD and ROD bit

v2: _ Replace opendrain bool type by u32
_ Clean opendrain bit management code

 drivers/mmc/host/mmci.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 8a4fbc2..f0edfe7 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -85,6 +85,7 @@
  * @mmcimask1: true if variant have a MMCIMASK1 register.
  * @start_err: bitmask identifying the STARTBITERR bit inside MMCISTATUS
  *register.
+ * @opendrain: bitmask identifying the OPENDRAIN bit inside MMCIPOWER register
  */
 struct variant_data {
unsigned intclkreg;
@@ -116,6 +117,7 @@ struct variant_data {
boolreversed_irq_handling;
boolmmcimask1;
u32 start_err;
+   u32 opendrain;
 };
 
 static struct variant_data variant_arm = {
@@ -127,6 +129,7 @@ struct variant_data {
.reversed_irq_handling  = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_ROD,
 };
 
 static struct variant_data variant_arm_extended_fifo = {
@@ -137,6 +140,7 @@ struct variant_data {
.f_max  = 1,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_ROD,
 };
 
 static struct variant_data variant_arm_extended_fifo_hwfc = {
@@ -148,6 +152,7 @@ struct variant_data {
.f_max  = 1,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_ROD,
 };
 
 static struct variant_data variant_u300 = {
@@ -165,6 +170,7 @@ struct variant_data {
.pwrreg_nopower = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_OD,
 };
 
 static struct variant_data variant_nomadik = {
@@ -183,6 +189,7 @@ struct variant_data {
.pwrreg_nopower = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_OD,
 };
 
 static struct variant_data variant_ux500 = {
@@ -207,6 +214,7 @@ struct variant_data {
.pwrreg_nopower = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_OD,
 };
 
 static struct variant_data variant_ux500v2 = {
@@ -233,6 +241,7 @@ struct variant_data {
.pwrreg_nopower = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_OD,
 };
 
 static struct variant_data variant_qcom = {
@@ -253,6 +262,7 @@ struct variant_data {
.qcom_dml   = true,
.mmcimask1  = true,
.start_err  = MCI_STARTBITERR,
+   .opendrain  = MCI_ROD,
 };
 
 /* Busy detection for the ST Micro variant */
@@ -1455,17 +1465,8 @@ static void mmci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
~MCI_ST_DATA2DIREN);
}
 
-   if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN) {
-   if (host->hw_designer != AMBA_VENDOR_ST)
-   pwr |= MCI_ROD;
-   else {
-   /*
-* The ST Micro variant use the ROD bit for something
-* else and only has OD (Open Drain).
-*/
-   pwr |= MCI_OD;
-   }
-   }
+   if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN && variant->opendrain)
+   pwr |= variant->opendrain;
 
/*
 * If clock = 0 and the variant requires the MMCIPOWER to be used for
-- 
1.9.1

[LTP] [ANNOUNCE] The Linux Test Project has been released for JANUARY 2018

[Cyril Hrubis]

Good news everyone,

the Linux Test Project test suite stable release for *January 2018* has been
released.

Since the last release 278 patches by 35 authors were merged.

Notable changes for this release include:
-

* New tests for:
  - unshare(1) command
  - ioctl07 test for RNDGETENTCNT ioctl()
  - new network MACsec testcases
  - new network IPsec SCTP and DCCP testcases

* New regression tests for:
  - CVE-2017-5754 aka meltdown
  - CVE-2017-12193 (test add_key04)
  - CVE-2017-15299 and CVE-2017-15951 (test request_key03)
  - CVE-2017-7308 (test setsockopt02)
  - CVE-2016-9604 (test keyctl08)
  - CVE-2017-15537 (test ptrace07)
  - CVE-2017-12192 (test keyctl07)
  - add_key03 regression test for kernel commit 237bbd29f7a0
  - keyctl06 regression test for kernel commit e645016abc80

* Fixed tests:
  - brk01 (test rewritten from scratch)
  - sigwaitinfo01 (fixed and enabled)
  - openposix aio testcases (uninitialized aiocb)
  + many smaller fixes

* Removed tests:
  - invalid openposix pthread_barrier_wait_6-1 test
  - tcp_cmds tests for rwho, echo, finger, and rdist.

* The test library gained support to run a particular test against
  different filesystems including FUSE filesystems such as NTFS or exFAT. The
  mkfs and kernel/FUSE support for a particular filesystem must be in-place
  otherwise the tests will skip it automatically.

  Some of the filesystem specific syscall tests such as fallocate() are
  executed this way now. We also have a new test that fills up filesystem
  using several threads and expects the syscalls to fail gracefully.

* The fuzzy synchronization library that is used to trigger races mostly in CVE
  testcases was rewritten to use one thread instead of starting a thread on
  each iteration, which is not only faster but also more stable since we
  introduce less random jitter to the timing measurements this way.

* Various fixes and enhancements for the network testcases.

* Support for NUMA API older than v2 was dropped from the testcases.

* The configure script now correctly detects devel libraries on -m32 build.

* Another large scale cleanup using coccinelle was done on the code base.

  We transformed patterns such as:

  if (scall(...) < 0)
  tst_brkm(TBROK, ...);

  into:

  SAFE_SCALL();

  Which will produce unified and more verbose error reporting in case
  that the call to scall() will fail.

* The runltp script now lists test skipped by the skipfile parameter as skipped
  in the testrun results, these were missing from it previously.

* 24 testcases were cleaned up and converted to the new test library

+ The usual amount of fixes all over the code base


Downloads and links:


The latest version of the test-suite contains 3000+ tests for the Linux
and can be downloaded at:

https://github.com/linux-test-project/ltp/releases/tag/20180118

The project pages as well as GIT repository are hosted on GitHub:

https://github.com/linux-test-project/ltp
http://linux-test-project.github.io/

If you ever wondered how to write a LTP testcase, don't miss our developer
documentation at:

https://github.com/linux-test-project/ltp/wiki/C-Test-Case-Tutorial
https://github.com/linux-test-project/ltp/wiki/Test-Writing-Guidelines
https://github.com/linux-test-project/ltp/wiki/BuildSystem

Patches, new tests, bugs, comments or questions should go to to our mailing
list at l...@lists.linux.it.

-- 
Cyril Hrubis
chru...@suse.cz

[PATCH 32/35] x86/vmx: Direct access to MSR_IA32_SPEC_CTRL

[Peter Zijlstra]

From: Ashok Raj 

Add direct access to MSR_IA32_SPEC_CTRL from a guest. Also save/restore
IBRS values during exits and guest resume path.

[peterz: rebased]

Cc: Asit Mallick 
Cc: Arjan Van De Ven 
Cc: Dave Hansen 
Cc: Andi Kleen 
Cc: Andrea Arcangeli 
Cc: Linus Torvalds 
Cc: Tim Chen 
Cc: Thomas Gleixner 
Cc: Dan Williams 
Cc: Jun Nakajima 
Cc: Paolo Bonzini 
Cc: David Woodhouse 
Cc: Greg KH 
Cc: Andy Lutomirski 
Signed-off-by: Ashok Raj 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/kvm/cpuid.c |3 ++-
 arch/x86/kvm/vmx.c   |   25 +
 arch/x86/kvm/x86.c   |1 +
 3 files changed, 28 insertions(+), 1 deletion(-)

--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void)
 /* These are scattered features in cpufeatures.h. */
 #define KVM_CPUID_BIT_AVX512_4VNNIW 2
 #define KVM_CPUID_BIT_AVX512_4FMAPS 3
+#define KVM_CPUID_BIT_SPEC_CTRL26
 #define KF(x) bit(KVM_CPUID_BIT_##x)
 
 int kvm_update_cpuid(struct kvm_vcpu *vcpu)
@@ -392,7 +393,7 @@ static inline int __do_cpuid_ent(struct
 
/* cpuid 7.0.edx*/
const u32 kvm_cpuid_7_0_edx_x86_features =
-   KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS);
+   KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS) | KF(SPEC_CTRL);
 
/* all calls to cpuid_count() should be made on the same cpu */
get_cpu();
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -580,6 +580,7 @@ struct vcpu_vmx {
u32 vm_entry_controls_shadow;
u32 vm_exit_controls_shadow;
u32 secondary_exec_control;
+   u64 spec_ctrl;
 
/*
 * loaded_vmcs points to the VMCS currently used in this vcpu. For a
@@ -3260,6 +3261,9 @@ static int vmx_get_msr(struct kvm_vcpu *
case MSR_IA32_TSC:
msr_info->data = guest_read_tsc(vcpu);
break;
+   case MSR_IA32_SPEC_CTRL:
+   msr_info->data = to_vmx(vcpu)->spec_ctrl;
+   break;
case MSR_IA32_SYSENTER_CS:
msr_info->data = vmcs_read32(GUEST_SYSENTER_CS);
break;
@@ -3367,6 +3371,9 @@ static int vmx_set_msr(struct kvm_vcpu *
case MSR_IA32_TSC:
kvm_write_tsc(vcpu, msr_info);
break;
+   case MSR_IA32_SPEC_CTRL:
+   to_vmx(vcpu)->spec_ctrl = msr_info->data;
+   break;
case MSR_IA32_CR_PAT:
if (vmcs_config.vmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) {
if (!kvm_mtrr_valid(vcpu, MSR_IA32_CR_PAT, data))
@@ -6791,6 +6798,13 @@ static __init int hardware_setup(void)
kvm_tsc_scaling_ratio_frac_bits = 48;
}
 
+   /*
+* If feature is available then setup MSR_IA32_SPEC_CTRL to be in
+* passthrough mode for the guest.
+*/
+   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL))
+   vmx_disable_intercept_for_msr(MSR_IA32_SPEC_CTRL, false);
+
vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
vmx_disable_intercept_for_msr(MSR_GS_BASE, false);
vmx_disable_intercept_for_msr(MSR_KERNEL_GS_BASE, true);
@@ -9299,6 +9313,15 @@ static void __noclone vmx_vcpu_run(struc
vmx_arm_hv_timer(vcpu);
 
vmx->__launched = vmx->loaded_vmcs->launched;
+
+   /*
+* Just update whatever the value was set for the MSR in guest.
+* If this is unlaunched: Assume that initialized value is 0.
+* IRQ's also need to be disabled. If guest value is 0, an interrupt
+* could start running in unprotected mode (i.e with IBRS=0).
+*/
+   restore_indirect_branch_speculation(vmx->spec_ctrl);
+
asm(
/* Store host registers */
"push %%" _ASM_DX "; push %%" _ASM_BP ";"
@@ -9407,6 +9430,8 @@ static void __noclone vmx_vcpu_run(struc
/* Eliminate branch target predictions from guest mode */
vmexit_fill_RSB();
 
+   vmx->spec_ctrl = stop_indirect_branch_speculation_and_save();
+
/* MSR_IA32_DEBUGCTLMSR is zeroed on vmexit. Restore it if needed */
if (debugctlmsr)
update_debugctlmsr(debugctlmsr);
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -1006,6 +1006,7 @@ static u32 msrs_to_save[] = {
 #endif
MSR_IA32_TSC, MSR_IA32_CR_PAT, MSR_VM_HSAVE_PA,
MSR_IA32_FEATURE_CONTROL, MSR_IA32_BNDCFGS, MSR_TSC_AUX,
+   MSR_IA32_SPEC_CTRL,
 };
 
 static unsigned num_msrs_to_save;

Re: [PATCH v2 02/10] x86: Update _static_cpu_has to use all named variables

[Borislav Petkov]

On Thu, Jan 18, 2018 at 04:09:40PM +0100, Peter Zijlstra wrote:
> You mean the subject alone don't count?

Yeah. Those empty commit messages make it look like a private repo with
WIP patches. The crap I have here.

:-)

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v4 4/8] PCI: brcmstb: Add dma-range mapping for inbound traffic

[Christoph Hellwig]

On Thu, Jan 18, 2018 at 07:09:23AM -0800, Florian Fainelli wrote:
> >But in this case it actually is the example to follow as told
> >previously.
> >
> >NAK again for these chained dma ops that only create problems.
> 
> Care to explain what should be done instead?

Override phys_to_dma and dma_to_phys as mips and x86 do for similar
situations.

Bonous points of finding some generic way of doing it instead of
hiding it in arch code.

Re: [PATCH V5 1/2] nvme-pci: introduce RECONNECTING state to mark initializing procedure

[James Smart]

On 1/18/2018 2:10 AM, Jianchao Wang wrote:

After Sagi's commit (nvme-rdma: fix concurrent reset and reconnect),
both nvme-fc/rdma have following pattern:
RESETTING- quiesce blk-mq queues, teardown and delete queues/
connections, clear out outstanding IO requests...
RECONNECTING - establish new queues/connections and some other
initializing things.
Introduce RECONNECTING to nvme-pci transport to do the same mark.
Then we get a coherent state definition among nvme pci/rdma/fc
transports.

Suggested-by: James Smart 
Signed-off-by: Jianchao Wang 
---
  drivers/nvme/host/core.c |  2 +-
  drivers/nvme/host/pci.c  | 19 +--
  2 files changed, 18 insertions(+), 3 deletions(-)



Reviewed-by: James Smart  

Re: [PATCH 34/35] x86/kvm: Add IBPB support

[Paolo Bonzini]

On 18/01/2018 14:48, Peter Zijlstra wrote:
> From: Ashok Raj 
> 
> Add MSR passthrough for MSR_IA32_PRED_CMD and place branch predictor
> barriers on switching between VMs to avoid inter VM specte-v2 attacks.
> 
> [peterz: rebase and changelog rewrite]
> 
> Cc: Asit Mallick 
> Cc: Dave Hansen 
> Cc: Arjan Van De Ven 
> Cc: Tim Chen 
> Cc: Linus Torvalds 
> Cc: Andrea Arcangeli 
> Cc: Andi Kleen 
> Cc: Thomas Gleixner 
> Cc: Dan Williams 
> Cc: Jun Nakajima 
> Cc: Andy Lutomirski 
> Cc: Greg KH 
> Cc: David Woodhouse 
> Cc: Paolo Bonzini 
> Signed-off-by: Ashok Raj 
> Signed-off-by: Peter Zijlstra (Intel) 
> ---
>  arch/x86/kvm/svm.c |8 
>  arch/x86/kvm/vmx.c |8 
>  2 files changed, 16 insertions(+)

This patch is missing the AMD-specific CPUID bit.

In addition, it is not bisectable because guests will see the SPEC_CTRL CPUID
bit after patch 32 even if PRED_CMD is not supported yet.

The simplest solutions are:

1) add the indirect_branch_prediction_barrier() calls first, and squash
everything else including the AMD CPUID bit into a single patch.  

2) place the IBPB in this series, and only add stop/restart_indirect_branch_
speculation() to the vmexit and vmentry paths.  We will do the guest enabling
in kvm.git after this is ready, it should only take a week and we'll ensure
it is backportable to 4.14 and 4.15.

3) same as (2) except we'll send the guest enabling through TIP.

Paolo

> --- a/arch/x86/kvm/svm.c
> +++ b/arch/x86/kvm/svm.c
> @@ -252,6 +252,7 @@ static const struct svm_direct_access_ms
>   { .index = MSR_SYSCALL_MASK,.always = true  },
>  #endif
>   { .index = MSR_IA32_SPEC_CTRL,  .always = true  },
> + { .index = MSR_IA32_PRED_CMD,   .always = true },
>   { .index = MSR_IA32_LASTBRANCHFROMIP,   .always = false },
>   { .index = MSR_IA32_LASTBRANCHTOIP, .always = false },
>   { .index = MSR_IA32_LASTINTFROMIP,  .always = false },
> @@ -532,6 +533,7 @@ struct svm_cpu_data {
>   struct kvm_ldttss_desc *tss_desc;
>  
>   struct page *save_area;
> + struct vmcb *current_vmcb;
>  };
>  
>  static DEFINE_PER_CPU(struct svm_cpu_data *, svm_data);
> @@ -1709,11 +1711,13 @@ static void svm_free_vcpu(struct kvm_vcp
>   __free_pages(virt_to_page(svm->nested.msrpm), MSRPM_ALLOC_ORDER);
>   kvm_vcpu_uninit(vcpu);
>   kmem_cache_free(kvm_vcpu_cache, svm);
> + indirect_branch_prediction_barrier();
>  }
>  
>  static void svm_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
>  {
>   struct vcpu_svm *svm = to_svm(vcpu);
> + struct svm_cpu_data *sd = per_cpu(svm_data, cpu);
>   int i;
>  
>   if (unlikely(cpu != vcpu->cpu)) {
> @@ -1742,6 +1746,10 @@ static void svm_vcpu_load(struct kvm_vcp
>   if (static_cpu_has(X86_FEATURE_RDTSCP))
>   wrmsrl(MSR_TSC_AUX, svm->tsc_aux);
>  
> + if (sd->current_vmcb != svm->vmcb) {
> + sd->current_vmcb = svm->vmcb;
> + indirect_branch_prediction_barrier();
> + }
>   avic_vcpu_load(vcpu, cpu);
>  }
>  
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -2280,6 +2280,7 @@ static void vmx_vcpu_load(struct kvm_vcp
>   if (per_cpu(current_vmcs, cpu) != vmx->loaded_vmcs->vmcs) {
>   per_cpu(current_vmcs, cpu) = vmx->loaded_vmcs->vmcs;
>   vmcs_load(vmx->loaded_vmcs->vmcs);
> + indirect_branch_prediction_barrier();
>   }
>  
>   if (!already_loaded) {
> @@ -3837,6 +3838,11 @@ static void free_loaded_vmcs(struct load
>   free_vmcs(loaded_vmcs->vmcs);
>   loaded_vmcs->vmcs = NULL;
>   WARN_ON(loaded_vmcs->shadow_vmcs != NULL);
> + /*
> +  * The VMCS could be recycled, causing a false negative in vmx_vcpu_load
> +  * block speculative execution.
> +  */
> + indirect_branch_prediction_barrier();

This IBPB is not needed, as loaded_vmcs->NULL is now NULL and there will be a
barrier the next time vmx_vcpu_load is called on this CPU.

Thanks,

Paolo

>  }
>  
>  static void free_kvm_area(void)
> @@ -6804,6 +6810,8 @@ static __init int hardware_setup(void)
>*/
>   if (boot_cpu_has(X86_FEATURE_SPEC_CTRL))
>   vmx_disable_intercept_for_msr(MSR_IA32_SPEC_CTRL, false);
> + if (boot_cpu_has(X86_FEATURE_IBPB))
> + vmx_disable_intercept_for_msr(MSR_IA32_PRED_CMD, false);
>  
>   vmx_disable_intercept_for_msr(MSR_FS_BASE, false);
>   vmx_disable_intercept_for_msr(MSR_GS_BASE, false);
> 
> 

Re: [PATCH v3 1/2] nvme: add tracepoint for nvme_setup_cmd

[Johannes Thumshirn]

On Thu, Jan 18, 2018 at 04:21:34PM +0100, Christoph Hellwig wrote:
> On Wed, Jan 17, 2018 at 11:53:35AM +0100, Johannes Thumshirn wrote:
> > +nvme-core-y:= trace.o core.o
> 
> trace.o should be conditional on CONFIG_TRACEPOINTS.
 
Doesn't do too much of a difference for me if CONFIG_TRACEPOINTS=n but if you
insist I can do it of cause.

> > +TRACE_EVENT(nvme_setup_cmd,
> > +   TP_PROTO(struct nvme_command *cmd),
> > +   TP_ARGS(cmd),
> > +   TP_STRUCT__entry(
> > +   __field(__u8, opcode)
> > +   __field(__u8, flags)
> > +   __field(__u16, cid)
> > +   __field(__le32, nsid)
> > +   __field(__le64, metadata)
> > +   __field_struct( struct nvme_command, cmnd )
> 
> This still copies the whole SQE.  I think that is way to much to
> copy, especially given that you also copy many of the fields separately
> as well.

it's not that much, but ok.

Will be sending out a v4 tomorrow.

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH v4 08/13] iommu/rockchip: Control clocks needed to access the IOMMU

[Robin Murphy]

On 18/01/18 11:52, Jeffy Chen wrote:

From: Tomasz Figa 

Current code relies on master driver enabling necessary clocks before
IOMMU is accessed, however there are cases when the IOMMU should be
accessed while the master is not running yet, for example allocating
V4L2 videobuf2 buffers, which is done by the VB2 framework using DMA
mapping API and doesn't engage the master driver at all.

This patch fixes the problem by letting clocks needed for IOMMU
operation to be listed in Device Tree and making the driver enable them
for the time of accessing the hardware.


Is it worth using the clk_bulk_*() APIs for this? At a glance, most of 
the code being added here appears to duplicate what those functions 
already do (but I'm no clk API expert, for sure).


Robin.


Signed-off-by: Jeffy Chen 
Signed-off-by: Tomasz Figa 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

  .../devicetree/bindings/iommu/rockchip,iommu.txt   |   8 ++
  drivers/iommu/rockchip-iommu.c | 114 +++--
  2 files changed, 116 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt 
b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
index 2098f7732264..33dd853359fa 100644
--- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
+++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt
@@ -14,6 +14,13 @@ Required properties:
  "single-master" device, and needs no additional 
information
  to associate with its master device.  See:
  Documentation/devicetree/bindings/iommu/iommu.txt
+Optional properties:
+- clocks : A list of master clocks requires for the IOMMU to be accessible
+   by the host CPU. The number of clocks depends on the master
+   block and might as well be zero. See [1] for generic clock
+   bindings description.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
  
  Optional properties:

  - rockchip,disable-mmu-reset : Don't use the mmu reset operation.
@@ -27,5 +34,6 @@ Example:
reg = <0xff940300 0x100>;
interrupts = ;
interrupt-names = "vopl_mmu";
+   clocks = < ACLK_VOP1>, < DCLK_VOP1>, < HCLK_VOP1>;
#iommu-cells = <0>;
};
diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
index 1914ac52042c..9b85a3050449 100644
--- a/drivers/iommu/rockchip-iommu.c
+++ b/drivers/iommu/rockchip-iommu.c
@@ -4,6 +4,7 @@
   * published by the Free Software Foundation.
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -89,6 +90,8 @@ struct rk_iommu {
struct device *dev;
void __iomem **bases;
int num_mmu;
+   struct clk **clocks;
+   int num_clocks;
bool reset_disabled;
struct iommu_device iommu;
struct list_head node; /* entry in rk_iommu_domain.iommus */
@@ -443,6 +446,83 @@ static int rk_iommu_force_reset(struct rk_iommu *iommu)
return 0;
  }
  
+static void rk_iommu_put_clocks(struct rk_iommu *iommu)

+{
+   int i;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   clk_unprepare(iommu->clocks[i]);
+   clk_put(iommu->clocks[i]);
+   }
+}
+
+static int rk_iommu_get_clocks(struct rk_iommu *iommu)
+{
+   struct device_node *np = iommu->dev->of_node;
+   int ret;
+   int i;
+
+   ret = of_count_phandle_with_args(np, "clocks", "#clock-cells");
+   if (ret == -ENOENT)
+   return 0;
+   else if (ret < 0)
+   return ret;
+
+   iommu->num_clocks = ret;
+   iommu->clocks = devm_kcalloc(iommu->dev, iommu->num_clocks,
+sizeof(*iommu->clocks), GFP_KERNEL);
+   if (!iommu->clocks)
+   return -ENOMEM;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   iommu->clocks[i] = of_clk_get(np, i);
+   if (IS_ERR(iommu->clocks[i])) {
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   ret = clk_prepare(iommu->clocks[i]);
+   if (ret) {
+   clk_put(iommu->clocks[i]);
+   iommu->num_clocks = i;
+   goto err_clk_put;
+   }
+   }
+
+   return 0;
+
+err_clk_put:
+   rk_iommu_put_clocks(iommu);
+
+   return ret;
+}
+
+static int rk_iommu_enable_clocks(struct rk_iommu *iommu)
+{
+   int i, ret;
+
+   for (i = 0; i < iommu->num_clocks; ++i) {
+   ret = clk_enable(iommu->clocks[i]);
+   if (ret)
+   goto err_disable;
+   }
+
+   return 0;
+
+err_disable:
+   for (--i; i >= 0; --i)
+   clk_disable(iommu->clocks[i]);
+
+   return ret;
+}
+
+static void rk_iommu_disable_clocks(struct rk_iommu 

Re: [PATCH v1 tip/master 0/3] kprobes/x86: retpoline: Fix kprobes for retpoline

[Andi Kleen]

> Side effect: [1/3] will move __x86_indirect_thunk_* functions
> in kernel text area. Of course those functions were in the
> .text area, but placed in right after _etext. This just moves
> it right before the _etext.

I assume you tested that with page table isolation on?

The thunks need to be accessible from the trampoline.

-Andi

[PATCH v3] fscrypt: add support for the encrypted key type

[André Draszik]

fscrypt uses a master key for each directory policy from
which all further keys for that policy are derived, and
at the moment such a master key has to be inserted into
a kernel keyring as a 'logon' key by user-space.

While 'logon' keys have the nice property of not being
readable by user-space (keyctl dump etc.), the fscrypt
master key still needs to be generated initially, in a
secure way, and it needs to be saved somewhere for
subsequent reboots, and hence also needs securing itself.

Usage of the 'logon' key means that it is up to user-space
to do all that, opening up the possibility of creating
cryptographically non-sound master keys, or not storing
the master key securely across reboots.

One approach for securing the master key would be to do
that using a TPM and while one could manually do so e.g.
using tpm-tools, that still leaves creation and actual
correct usage of tpm-tools up to user-space, though. As an
aside, tpm-tools needs the tcsd daemon running, which makes
it awkward to use from within an initramfs, and while other
libraries for interfacing with a TPM do exist, there
appears to be a better way:

The kernel already has a concept of trusted as well as
encrypted keys. Trusted keys are TPM backed keys, which can
be sealed to PCRs and also easily be re-sealed against new
future PCRs, and encrypted keys are keys that are encrypted
using another key, e.g. a trusted key. All are generated
automatically by the kernel using the RNG and never leave
kernel memory space (bar any kernel or hardware bugs).

So it seems reasonable to allow the fscrypt subsystem to
work with encrypted keys as well. This is what this change
here does.

We can utilise keys that never ever exist in user-space,
not even at initial creation time, as well as simplifying
usage / configuration. Something very very similar exists
for eCrypts already.

With these patches, we can

kmk_id=$(keyctl add trusted kmk "new 128 [pcrinfo=...]" @u)
fscrypt_id=$(keyctl add encrypted fscrypt:1234567890123456 "new default 
trusted:kmk 64" @u)
fscryptctl set_policy 1234567890123456 /encrypted

then we can save those keys for after reboot (optionally
TPM-sealed as per the pcrinfo= argument above):

keyctl pipe ${kmk_id} > /keys/kmk.blob
keyctl pipe ${fscrypt_id} > /keys/fscrypt.blob

and on subsequent boots we can simply insert them again
(optionally benefitting from the TPM's capability to only
unseal kmk.blob when the system is in the expected state,
thereby also protecting fscrypt.blob):

keyctl add trusted kmk "load $(cat /keys/kmk.blob)" @u
keyctl add encrypted fscrypt:1234567890123456 "load $(cat 
/keys/fscrypt.blob)" @u

Signed-off-by: André Draszik 
Cc: Mimi Zohar 
Cc: David Howells 
Cc: James Morris 
Cc: "Serge E. Hallyn" 
Cc: "Theodore Y. Ts'o" 
Cc: Jaegeuk Kim 
Cc: Kees Cook 
Cc: Eric Biggers 
Cc: linux-integr...@vger.kernel.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: linux-fscr...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org

---
changes in v3:
* merge documentation changes into this commit
* update derive_key_aes() signature to not take
  a struct fscrypt_key and update all callers
* try to use the 'encrypted' key as fallback only
  if the a 'logon' key isn't present (ENOKEY)
* update fscrypt_get_encrypted_key() to take a
  'description', not a 'sig'
* update commit message
* re-add keyrings mailing list and encrypted-keys
  maintainers to Cc

changes in v2:
* dropped the previously added 'fscrypt' encrypted-key,
  and just use the 'default' format
---
 Documentation/filesystems/fscrypt.rst | 56 +++--
 fs/crypto/keyinfo.c   | 92 ++-
 2 files changed, 110 insertions(+), 38 deletions(-)

diff --git a/Documentation/filesystems/fscrypt.rst 
b/Documentation/filesystems/fscrypt.rst
index 776ddc655f79..852ac2900b66 100644
--- a/Documentation/filesystems/fscrypt.rst
+++ b/Documentation/filesystems/fscrypt.rst
@@ -368,11 +368,19 @@ Adding keys
 To provide a master key, userspace must add it to an appropriate
 keyring using the add_key() system call (see:
 ``Documentation/security/keys/core.rst``).  The key type must be
-"logon"; keys of this type are kept in kernel memory and cannot be
-read back by userspace.  The key description must be "fscrypt:"
-followed by the 16-character lower case hex representation of the
-``master_key_descriptor`` that was set in the encryption policy.  The
-key payload must conform to the following structure::
+either "logon" or "encrypted"; "logon" keys are kept in kernel
+memory and cannot be read back by userspace while "encrypted"
+keys can be rooted in a "trusted" key and thus are protected by
+a TPM and cannot be read by userspace in unencrypted form. Note
+that while an "encrypted" key can 

RE: [PATCH] USB TYPEC: RT1711H Type-C Chip Driver

[李書帆]

Dear Gerg,

  Many thanks to your comment.
  I've checked all of them and here are some questions need your help.

> +Example:
> +rt1711h@4e {
> +status = "ok";
> +compatible = "richtek,typec_rt1711h";
> +reg = <0x4e>;
> +rt,intr_gpio = < 0 0x0>;
> +rt,name = "rt1711h";
> +rt,port_type = <2>; /* 0: DFP, 1: UFP, 2: DRP */
> +rt,def_role = <0>; /* 0: SNK, 1: SRC, -1: TYPEC_NO_PREFERRED_ROLE */
> +};

dts stuff needs to always be in a separate file so the DT maintainers can 
review/ack it.  Split this patch up into smaller pieces please.

Ok, I'll split it into two patches, one for source code and once for dts 
related files.


> diff --git a/drivers/usb/typec/Makefile b/drivers/usb/typec/Makefile
> index bb3138a..e3aaf3c 100644
> --- a/drivers/usb/typec/Makefile
> +++ b/drivers/usb/typec/Makefile
> @@ -2,6 +2,7 @@
>  obj-$(CONFIG_TYPEC)+= typec.o
>  obj-$(CONFIG_TYPEC_TCPM)+= tcpm.o
>  obj-y+= fusb302/
> +obj-$(CONFIG_TYPEC_RT1711H)+= rt1711h/

Why do you need a whole directory for one file?

Is the suggestion to move rt1711h.c to the same directory level as tcpm? i.e. 
drivers/usb/typec/rt1711h.c


> +

This last #include should not be needed.  If it does, you are doing something 
really wrong...

Ok, this #include will be removed


> +
> +#include "rt1711h.h"

Why a .h file for a single .c file?

Is the suggestion to move all content in rt1711h.h into rt1711h.c?


> +
> +#define RT1711H_DRV_VERSION"1.0.3"

When code is in the kernel tree, versions mean nothing, you will note that no 
other USB driver has them, right?  Please remove.

Ok, this will be removed.


kernel types are u16, u32, u8, and the like, not uint16_t, those are for 
userspace code only.
Yeah, other drivers do it, but you shouldn't :)

Ok, I'll use u16, u32 and u8 instead of uint16_t, uint32_t and uint8_t


> +/* IRQ */
> +struct kthread_worker irq_worker;
> +struct kthread_work irq_work;
> +struct task_struct *irq_worker_task;

3 things for an irq handler?  That feels wrong.

> +atomic_t poll_count;

Like I said before, why is this an atomic?

I'll use threaded_irq instead, the above things will be removed.


> +/* I2C */
> +atomic_t i2c_busy;
> +atomic_t pm_suspend;

Why are these atomic?  You know that doesn't mean they do not need locking, 
right?

For my understanding, a single operation on atomic_t doesn't need lock, like a 
single atomic_set.
But two consecutive operations doesn't guarantee anything. Like atomic_set 
followed by an atomic_read.
This part is referenced from fusb302 used to make sure I2C is idle before 
system suspends.
It only needs to guarantee a single read/write on these variable is atomic 
operation, so atomic is used.


> +};
> +
> +/*
> + * Logging & debugging
> + */
> +
> +#ifdef CONFIG_DEBUG_FS
> +
> +static int rt1711h_reg_block_read(struct rt1711h_chip *chip, uint8_t reg,
> +int len, uint8_t *data);
> +static int rt1711h_reg_block_write(struct rt1711h_chip *chip, uint8_t reg,
> +int len, const uint8_t *data);
> +
> +struct reg_desc {
> +uint8_t addr;
> +uint8_t size;
> +};
> +#define DECL_REG(_addr, _size) {.addr = _addr, .size = _size}
> +
> +static struct reg_desc rt1711h_reg_desc[] = {
> +DECL_REG(RT1711H_REG_VID, 2),
> +DECL_REG(RT1711H_REG_PID, 2),
> +DECL_REG(RT1711H_REG_DID, 2),
> +DECL_REG(RT1711H_REG_TYPEC_REV, 2),
> +DECL_REG(RT1711H_REG_PD_REV, 2),
> +DECL_REG(RT1711H_REG_PDIF_REV, 2),
> +DECL_REG(RT1711H_REG_ALERT, 2),
> +DECL_REG(RT1711H_REG_ALERT_MASK, 2),
> +DECL_REG(RT1711H_REG_POWER_STATUS_MASK, 1),
> +DECL_REG(RT1711H_REG_FAULT_STATUS_MASK, 1),
> +DECL_REG(RT1711H_REG_TCPC_CTRL, 1),
> +DECL_REG(RT1711H_REG_ROLE_CTRL, 1),
> +DECL_REG(RT1711H_REG_FAULT_CTRL, 1),
> +DECL_REG(RT1711H_REG_POWER_CTRL, 1),
> +DECL_REG(RT1711H_REG_CC_STATUS, 1),
> +DECL_REG(RT1711H_REG_POWER_STATUS, 1),
> +DECL_REG(RT1711H_REG_FAULT_STATUS, 1),
> +DECL_REG(RT1711H_REG_COMMAND, 1),
> +DECL_REG(RT1711H_REG_MSG_HDR_INFO, 1),
> +DECL_REG(RT1711H_REG_RX_DETECT, 1),
> +DECL_REG(RT1711H_REG_RX_BYTE_CNT, 1),
> +DECL_REG(RT1711H_REG_RX_BUF_FRAME_TYPE, 1),
> +DECL_REG(RT1711H_REG_RX_HDR, 2),
> +DECL_REG(RT1711H_REG_RX_DATA, 1),
> +DECL_REG(RT1711H_REG_TRANSMIT, 1),
> +DECL_REG(RT1711H_REG_TX_BYTE_CNT, 1),
> +DECL_REG(RT1711H_REG_TX_HDR, 2),
> +DECL_REG(RT1711H_REG_TX_DATA, 1),
> +DECL_REG(RT1711H_REG_CLK_CTRL2, 1),
> +DECL_REG(RT1711H_REG_CLK_CTRL3, 1),
> +DECL_REG(RT1711H_REG_BMC_CTRL, 1),
> +DECL_REG(RT1711H_REG_BMCIO_RXDZSEL, 1),
> 

Re: [PATCH V5 4/8] perf/x86/intel/uncore: add new data structures for free running counters

[Peter Zijlstra]

On Mon, Jan 15, 2018 at 10:57:05AM -0800, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> There are a number of free running counters introduced for uncore, which
> provide highly valuable information to a wide array of customers.
> For example, Skylake Server has IIO free running counters to collect
> Input/Output x BW/Utilization.
> The precious generic counters could be saved to collect other customer
> interested data.
> 
> The free running counter is read-only and always active. Current generic
> uncore code does not support this kind of counters.
> 
> Introduce a new index to indicate the free running counters. Only one
> index is enough for all free running counters. Because the free running
> countes are always active, and the event and free running counter are
> always 1:1 mapped. It does not need extra index to indicate the assigned
> counter.
> 
> Introduce some rules to encode the event for free running counters.
> - The event for free running counter has the same event code 0xff as the
>   event for fixed counter.
> - The umask of the event starts from 0x10. The umask which is less than
>   0x10 is reserved for the event of fixed counter.
> - The free running counters can be divided into different types
>   according to the MSR location, bit width or definition. The start
>   point of the umask for different type has 0x10 offset.
> For example, there are three types of IIO free running counters on
> Skylake server, IO CLOCKS counters, BANDWIDTH counters and UTILIZATION
> counters.
> The event code for all free running counters is 0xff.
> 'ioclk' is the first counter of IO CLOCKS. IO CLOCKS is the first type
> of free running counters, which umask starts from 0x10.
> So 'ioclk' is encoded as event=0xff,umask=0x10
> 'bw_in_port2' is the third counter of BANDWIDTH counters. BANDWIDTH is
> the second type which umask starts from 0x20.
> So 'bw_in_port2' is encoded as event=0xff,umask=0x22.
> 
> Introduce a new data structure to store free running counters related
> information for each type. It includes the number of counters, bit
> width, base address, offset between counters and offset between boxes.
> 
> Introduce several inline helpers to check index for fixed counter and
> free running counter, validate free running counter event, and retrieve
> the free running counter information according to box and event.

Sorry, none of this makes any sense, what?

WTH would all free running counters, which presumably count different
things, have the same event code ?

And whats the hackery with the umask do?

Please rewrite this in comprehensible form and also give rationale for
the various choices.

Re: [PATCH v2 07/10] x86/jump_label: Implement arch_static_assert()

[Borislav Petkov]

On Tue, Jan 16, 2018 at 03:28:32PM +0100, Peter Zijlstra wrote:
> Implement the static (branch) assertion. It simply emits the address
> of the next instruction into a special section which objtool will read
> and validate against either __jump_table or .altinstructions.
> 
> Use like:
> 
>   if (static_branch_likely(_key)) {
>   arch_static_assert();
>   /* do stuff */
>   }
> 
> Or
> 
>   if (static_cpu_has(_feat)) {
>   arch_static_assert();

It looks to me like the asserts can be moved into the macros and the
assertion checking can happen by default ...?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v22 2/3] virtio-balloon: VIRTIO_BALLOON_F_FREE_PAGE_VQ

[Tetsuo Handa]

On 2018/01/18 1:44, Michael S. Tsirkin wrote:
>> +static void add_one_sg(struct virtqueue *vq, unsigned long pfn, uint32_t 
>> len)
>> +{
>> +struct scatterlist sg;
>> +unsigned int unused;
>> +int err;
>> +
>> +sg_init_table(, 1);
>> +sg_set_page(, pfn_to_page(pfn), len, 0);
>> +
>> +/* Detach all the used buffers from the vq */
>> +while (virtqueue_get_buf(vq, ))
>> +;
>> +
>> +/*
>> + * Since this is an optimization feature, losing a couple of free
>> + * pages to report isn't important.
>> We simply resturn
> 
> return
> 
>> without adding
>> + * the page if the vq is full. We are adding one entry each time,
>> + * which essentially results in no memory allocation, so the
>> + * GFP_KERNEL flag below can be ignored.
>> + */
>> +if (vq->num_free) {
>> +err = virtqueue_add_inbuf(vq, , 1, vq, GFP_KERNEL);
> 
> Should we kick here? At least when ring is close to
> being full. Kick at half way full?
> Otherwise it's unlikely ring will
> ever be cleaned until we finish the scan.

Since this add_one_sg() is called between spin_lock_irqsave(>lock, flags)
and spin_unlock_irqrestore(>lock, flags), it is not permitted to sleep.
And walk_free_mem_block() is not ready to handle resume.

By the way, specifying GFP_KERNEL here is confusing even though it is never 
used.
walk_free_mem_block() says:

  * The callback itself must not sleep or perform any operations which would
  * require any memory allocations directly (not even GFP_NOWAIT/GFP_ATOMIC)
  * or via any lock dependency. 

> 
>> +/*
>> + * This is expected to never fail, because there is always an
>> + * entry available on the vq.
>> + */
>> +BUG_ON(err);
>> +}
>> +}

Re: [PATCH v2 01/10] perf tools: Integrating the CoreSight decoding library

[Arnaldo Carvalho de Melo]

Em Wed, Jan 17, 2018 at 09:06:40AM +0100, Jiri Olsa escreveu:
> On Tue, Jan 16, 2018 at 01:30:33PM -0700, Mathieu Poirier wrote:
> > On 16 January 2018 at 05:15, Jiri Olsa  wrote:
> > > On Mon, Jan 15, 2018 at 11:13:05AM -0700, Mathieu Poirier wrote:
> > >> +++ b/tools/build/Makefile.feature
> > >> @@ -66,7 +66,8 @@ FEATURE_TESTS_BASIC :=  \
> > >>  bpf \
> > >>  sched_getcpu \
> > >>  sdt  \
> > >> -setns
> > >> +setns\
> > >> + libopencsd
> > >>
> > >>  # FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
> > >>  # of all feature tests
> > >> @@ -108,7 +109,8 @@ FEATURE_DISPLAY ?=  \
> > >>   zlib   \
> > >>   lzma   \
> > >>   get_cpuid  \
> > >> - bpf
> > >> + bpf \
> > >> +  libopencsd

> > > we put in this list only generic libraries, this one seems arch
> > > specific please put it into FEATURE_TESTS_EXTRA list

> > I was thinking that libopencsd should fall in the same category as
> > libunwind-arm and libunwind-aarch64.  Both are not architecture
> > specific and used to process traces acquired on ARM platforms.  As
> > such I suggest to keep libopencsd as part of FEATURE_TESTS_BASIC and
> > remove it from under FEATURE_DISPLAY - how does that sound to you?
 
> ok, that sounds good

Hi Jiri,

Shouldn't libopencsd be treated like libbabeltrace was before
the required version was widely available in distros?

I.e. these csets should have the rationale for that:

Enabling it once it became widely available:

   24787afbcd01 ("perf tools: Enable LIBBABELTRACE by default")

Disabling it because we would need to get things from tarballs/git
repos, build it in our machines, as requested by Ingo:

  6ab2b762befd ("perf build: Disable libbabeltrace check by default")

- Arnaldo

Re: dangers of bots on the mailing lists was Re: divide error in ___bpf_prog_run

[Henrique de Moraes Holschuh]

On Thu, 18 Jan 2018, Dmitry Vyukov wrote:
> I've made a bunch of changes yesterday and today. This includes

...

> and even per crash/tree. To alleviate this, syzbot will now say e.g.
> "So far this crash happened 185 times on linux-next, mmots, net-next,
> upstream". So that you can see that it's not only, say, linux-next
> problem.
> 
> syzbot just mailed another report with all of these changes which you
> can see here:
> https://groups.google.com/forum/#!msg/syzkaller-bugs/u5nq3PdPkIc/F4tXzErxAgAJ

Looks good to me.  Not that I had anything against what it did before,
but it is much more recipient-friendly now, IMHO.

Thanks for all the hard work on syzkaller!

-- 
  Henrique Holschuh

Re: [PATCH] kconfig: Document SYMBOL_OPTIONAL logic

[Masahiro Yamada]

2018-01-14 18:56 GMT+09:00 Ulf Magnusson :
> Not obvious, especially if you don't already know how choices are
> implemented.
>
> No functional changes. Only comments added.
>
> Signed-off-by: Ulf Magnusson 
> ---
>  scripts/kconfig/menu.c | 9 +
>  1 file changed, 9 insertions(+)
>
> diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
> index 92d3f06cd8a2..372eb5d9fef3 100644
> --- a/scripts/kconfig/menu.c
> +++ b/scripts/kconfig/menu.c
> @@ -548,6 +548,15 @@ void menu_finalize(struct menu *parent)
> sym->flags |= SYMBOL_WARNED;
> }
>
> +   /*
> +* For non-optional choices, add a reverse dependency (corresponding 
> to
> +* a select) of ' && m'. This prevents the user from
> +* setting the choice mode to 'n' when the choice is visible.
> +*
> +* This would also work for non-choice symbols, but only non-optional
> +* choices clear SYMBOL_OPTIONAL as of writing. Choices are 
> implemented
> +* as a type of symbol.
> +*/
> if (sym && !sym_is_optional(sym) && parent->prompt) {
> sym->rev_dep.expr = expr_alloc_or(sym->rev_dep.expr,
> expr_alloc_and(parent->prompt->visible.expr,
> --


Applied to linux-kbuild/kconfig.  Thanks!



-- 
Best Regards
Masahiro Yamada

Re: [PATCH -next] mtd: ubi: wl: Fix error return code in ubi_wl_init()

[Boris Brezillon]

On Thu, 18 Jan 2018 15:08:01 +0100
Boris Brezillon <boris.brezil...@free-electrons.com> wrote:

> On Thu, 18 Jan 2018 14:05:05 +
> Wei Yongjun <weiyongj...@huawei.com> wrote:
> 
> > Fix to return error code -ENOMEM from the kmem_cache_alloc() error
> > handling case instead of 0, as done elsewhere in this function.  
> 
> I guess you've used a static analysis code to detect this problem, can
> you name it in the commit message, and paste the error/warning message
> it reported next time you submit this kind of patch.
> 
> > 
> > Signed-off-by: Wei Yongjun <weiyongj...@huawei.com>  
> 
> NAck. I you read the code you'll see that err is initialized to -ENOMEM
> here [1], so these changes are actually not needed.

Sorry, just realized I was wrong. It seems that err can be overridden by
[2]. So this patch is indeed fixing a real problem.

Reviewed-by: Boris Brezillon <boris.brezil...@free-electrons.com>

> 
> > ---
> >  drivers/mtd/ubi/wl.c | 8 ++--
> >  1 file changed, 6 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
> > index 77ab49f..2052a64 100644
> > --- a/drivers/mtd/ubi/wl.c
> > +++ b/drivers/mtd/ubi/wl.c
> > @@ -1617,8 +1617,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
> > ubi_attach_info *ai)
> > cond_resched();
> >  
> > e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> > -   if (!e)
> > +   if (!e) {
> > +   err = -ENOMEM;
> > goto out_free;
> > +   }
> >  
> > e->pnum = aeb->pnum;
> > e->ec = aeb->ec;
> > @@ -1637,8 +1639,10 @@ int ubi_wl_init(struct ubi_device *ubi, struct 
> > ubi_attach_info *ai)
> > cond_resched();
> >  
> > e = kmem_cache_alloc(ubi_wl_entry_slab, GFP_KERNEL);
> > -   if (!e)
> > +   if (!e) {
> > +   err = -ENOMEM;
> >     goto out_free;
> > +   }
> >  
> > e->pnum = aeb->pnum;
> > e->ec = aeb->ec;
> >   
> 
> [1]https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mtd/ubi/wl.c?h=next-20180118#n1596

[2]https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/mtd/ubi/wl.c?h=next-20180118#n1609

Re: [PATCH 3/4] tsi108_eth: use dma API properly

[David Miller]

From: Bjorn Helgaas 
Date: Wed, 17 Jan 2018 18:08:18 -0600

> [+cc David, FYI, I plan to merge this via PCI along with the rest of
> Christoph's series]

No problem.

Re: [PATCH v4 05/13] iommu/rockchip: Use iopoll helpers to wait for hardware

[JeffyChen]

Hi Robin,

On 01/18/2018 09:09 PM, Robin Murphy wrote:

-#define FORCE_RESET_TIMEOUT100/* ms */
+#define FORCE_RESET_TIMEOUT10/* us */
+#define POLL_TIMEOUT1000/* us */


Nit: the callsites look a bit odd with the combination of POLL_TIMEOUT
and the magic number 100 - should we not also define something like
POLL_PERIOD for that? Also POLL_TIMEOUT is a rather generic name and
overlaps with several other drivers, so a namespace prefix would be
helpful (i.e. RK_IOMMU_POLL*, or at least RK_POLL*).

FWIW, my personal preference would be to also suffix these with _US for
absolute clarity, but it's not essential (especially if longer names
lead to more linebreaks at the callsites).

right, that make sense, will fix it in next version, thanks :)


With those undocumented "100"s fixed up,

Reviewed-by: Robin Murphy 

[PATCH] pinctrl: meson-axg: adjust uart_ao_b pin group naming

[Yixun Lan]

Simply adjust the pin group to _x _y _z style, as to
keep the consistency in DT with previous naming scheme.

Fixes: 83c566806a68 ("pinctrl: meson-axg: Add new pinctrl driver for Meson AXG 
SoC")
Signed-off-by: Yixun Lan 

---
Hi Linus,

 Please also consider merging this patch into 'for-next', since it
fixes issue added in the same cycle.
 This patch will also obsolete previous one patches [1]

[1] pinctrl: meson: use one uniform 'function' name
http://lkml.kernel.org/r/20180108073328.205769-1-yixun@amlogic.com
---
 drivers/pinctrl/meson/pinctrl-meson-axg.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pinctrl/meson/pinctrl-meson-axg.c 
b/drivers/pinctrl/meson/pinctrl-meson-axg.c
index 1fda9d6c7ea3..4b91ff74779b 100644
--- a/drivers/pinctrl/meson/pinctrl-meson-axg.c
+++ b/drivers/pinctrl/meson/pinctrl-meson-axg.c
@@ -716,7 +716,7 @@ static const char * const uart_b_groups[] = {
"uart_tx_b_x", "uart_rx_b_x", "uart_cts_b_x", "uart_rts_b_x",
 };
 
-static const char * const uart_ao_b_gpioz_groups[] = {
+static const char * const uart_ao_b_z_groups[] = {
"uart_ao_tx_b_z", "uart_ao_rx_b_z",
"uart_ao_cts_b_z", "uart_ao_rts_b_z",
 };
@@ -855,7 +855,7 @@ static struct meson_pmx_func meson_axg_periphs_functions[] 
= {
FUNCTION(nand),
FUNCTION(uart_a),
FUNCTION(uart_b),
-   FUNCTION(uart_ao_b_gpioz),
+   FUNCTION(uart_ao_b_z),
FUNCTION(i2c0),
FUNCTION(i2c1),
FUNCTION(i2c2),
-- 
2.15.1

Re: [PATCH v2 0/2] arm64: Run enable method for errata work arounds on late CPUs

[Suzuki K Poulose]

On 18/01/18 14:21, Dave Martin wrote:

On Thu, Jan 18, 2018 at 12:08:43PM +, Robin Murphy wrote:

On 18/01/18 12:00, Robin Murphy wrote:
[...]

+struct enable_arg {
+    int (*enable)(struct arm64_cpu_capabilities const *);
+    struct arm64_cpu_capabilities const *cap;
+};
+
+static int __enable_cpu_capability(void *arg)
+{
+    struct enable_arg const *e = arg;
+
+    return e->enable(e->cap);
+}


AFAICS, you shouldn't even need the intermediate struct - if you were
instead to call stop_machine(>enable, ...), the wrapper could be:

  **fn = arg;
 *fn(container_of(fn, struct arm64_cpu_capabilities, enable));

(cheaty pseudocode because there's no way I'm going to write a
pointer-to-function-pointer type correctly in an email client...)

That's certainly a fair bit simpler in terms of diffstat; whether it's
really as intuitive as I think it is is perhaps another matter, though.


Ah, right, but then you'd be back to casting away const, and at that point
it makes no sense to do the container_of dance instead of just passing the
struct pointer itself around...

I shall now excuse myself from this discussion, as I'm clearly not helping
:)

Robin.


That's what I was about to say... but neat trick.

However, it does concentrate the type fudge in one place and keeps the
arm64_cpu_capabilities::enable() prototype correct, so it's still better
than the original.


Thinking about it, the following is probably clearer and no worse:

static int __enable_cpu_capability(void *arg)
{
struct arm64_cpu_capabilities const *cap = arg;

return cap->enable(cap);
}

...

stop_machine(__enable_cpu_capability, (void *)caps, cpu_online_mask);


In your version, the argument would be (void *)>enable, which is
really just a proxy for (void *)caps, unless I missed something.


What do you think Suzuki?  I can respin my patch if you fancy picking it
up.  Either way, it's not urgent.


Thanks for cooking that up Dave & Robin. I prefer your second version.
Please feel free to respin it. As you rightly said, this is not urgent
and could pick it up in my re-writing of the capability infrastructure ;-)

Meanwhile, I would really like some reviews on the original patch and
push it for 4.16 (as a fix at least).

Cheers
Suzuki



Cheers
---Dave

[PATCH 1/2] clk: stm32: END_PRIMARY_CLK should be declare after CLK_SYSCLK

[gabriel.fernandez]

From: Gabriel Fernandez 

Update of END_PRIMARY_CLK was missed, it should be after CLK_SYSCLK
hsi and sysclk are overwritten by gpioa and gpiob.

Signed-off-by: Gabriel Fernandez 
---
 include/dt-bindings/clock/stm32fx-clock.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/dt-bindings/clock/stm32fx-clock.h 
b/include/dt-bindings/clock/stm32fx-clock.h
index 49bb3c2..4d523b0 100644
--- a/include/dt-bindings/clock/stm32fx-clock.h
+++ b/include/dt-bindings/clock/stm32fx-clock.h
@@ -33,11 +33,11 @@
 #define CLK_SAI2   11
 #define CLK_I2SQ_PDIV  12
 #define CLK_SAIQ_PDIV  13
-
-#define END_PRIMARY_CLK14
-
 #define CLK_HSI14
 #define CLK_SYSCLK 15
+
+#define END_PRIMARY_CLK16
+
 #define CLK_HDMI_CEC   16
 #define CLK_SPDIF  17
 #define CLK_USART1 18
-- 
1.9.1

Re: [PATCH v16 09/10] drm/panel: Use of_find_backlight helper

[Noralf Trønnes]

Den 18.01.2018 13.07, skrev Meghana Madhyastha:

On Tue, Jan 16, 2018 at 06:08:53PM +0100, Noralf Trønnes wrote:

Den 16.01.2018 11.36, skrev Meghana Madhyastha:

Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.

Signed-off-by: Meghana Madhyastha 
---
  drivers/gpu/drm/panel/panel-innolux-p079zca.c   | 10 +++---
  drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 +++---
  drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 +++---
  3 files changed, 9 insertions(+), 21 deletions(-)

diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c 
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 4c1b29eec..a69b0530f 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -230,14 +230,10 @@ static int innolux_panel_add(struct innolux_panel 
*innolux)
innolux->enable_gpio = NULL;
}
-   np = of_parse_phandle(dev->of_node, "backlight", 0);
-   if (np) {
-   innolux->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   innolux->backlight = devm_of_find_backlight(np);

This driver isn't broken like tinydrm was, so it does put the backlight
device on cleanup like it should. So when you're using the devm_ version,
the result is a double put. Just remove the put_device() in
innolux_panel_add/del() and you're good.

I have a quick question here. So devm_of_find_backlight automatically
does a put_device on detachment of the driver. However in this case,
put_device is called when panel_add is not successful (i.e when it
returns a negative value here). So is devm's release mechanism still
invoked here ?


As long as the error is propagated back up the chain, which it is in this
case, devres_release_all() is called and the resources are released.

Driver callchain passing up the error:
innolux_panel_driver.probe = innolux_panel_probe <- innolux_panel_add <- 
devm_of_find_backlight


This is mipi_dsi setting up the probe hook and calling into it's own 
version:


drivers/gpu/drm/drm_mipi_dsi.c:
int mipi_dsi_driver_register_full(struct mipi_dsi_driver *drv,
                  struct module *owner)
{
...
    if (drv->probe)
        drv->driver.probe = mipi_dsi_drv_probe;
...
}

static int mipi_dsi_drv_probe(struct device *dev)
{
    struct mipi_dsi_driver *drv = to_mipi_dsi_driver(dev->driver);
    struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);

    return drv->probe(dsi);
}

This is the device-driver core that initiates the probing:

drivers/base/dd.c
static int really_probe(struct device *dev, struct device_driver *drv)
{
...
    } else if (drv->probe) {
        ret = drv->probe(dev);
        if (ret)
            goto probe_failed;
    }
...
probe_failed:
...
    devres_release_all(dev);
...
}


err = drm_panel_add(>base);
if (err < 0)
goto put_backlight;

return 0;

put_backlight:
put_device(>backlight->dev);
return err;

If so then I should change this to
err = drm_panel_add(>base)
return err;


Yes, and you can drop the variable:

    return drm_panel_add(>base);

Noralf.



Thanks and regards,
Meghana


I haven't checked the other drivers.

Noralf.

PS:
Give people a few days (one week?) to respond before respinning a new
version, so we avoid a fragmented discussion.


-   if (!innolux->backlight)
-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(innolux->backlight))
+   return PTR_ERR(innolux->backlight);
drm_panel_init(>base);
innolux->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c 
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 1512ec4f3..d5450c9d9 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -329,14 +329,10 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
-   np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
-   if (np) {
-   sharp->backlight = of_find_backlight_by_node(np);
-   of_node_put(np);
+   sharp->backlight = devm_of_find_backlight(np);
-   if (!sharp->backlight)
-   return -EPROBE_DEFER;
-   }
+   if (IS_ERR(sharp->backlight))
+   return PTR_ERR(sharp->backlight);
drm_panel_init(>base);
sharp->base.funcs = _panel_funcs;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index a6af3257f..db31d8268 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -273,14 +273,10 @@ static int sharp_nt_panel_add(struct sharp_nt_panel 
*sharp_nt)

Re: [mm 4.15-rc8] Random oopses under memory pressure.

[Dave Hansen]

On 01/18/2018 06:45 AM, Kirill A. Shutemov wrote:
> On Thu, Jan 18, 2018 at 06:38:10AM -0800, Dave Hansen wrote:
>> On 01/18/2018 05:12 AM, Kirill A. Shutemov wrote:
>>> -   if (pte_page(*pvmw->pte) - pvmw->page >=
>>> -   hpage_nr_pages(pvmw->page)) {
>> Is ->pte guaranteed to map a page which is within the same section as
>> pvmw->page?  Otherwise, with sparsemem (non-vmemmap), the pointer
>> arithmetic won't work.
> No, it's not guaranteed. It can be arbitrary page.
> 
> The arithmetic won't work because they are different "memory objects"?

No, because sections' mem_map[]s can be allocated non-contiguously.
Section 1's might be a lower virtual address than Section 0's.

They're allocated not unlike this:

mem_section[0]->section_mem_map = kmalloc(SECTION_SIZE);
mem_section[1]->section_mem_map = kmalloc(SECTION_SIZE);
...

The first pfn in section 1 and the last pfn in section 0 are adjacent
PFNs, but their 'struct page' might have virtual addresses that are TB
apart.

[PATCH 00/35] jump_label, objtool, IBRS and IBPB

[Peter Zijlstra]

Lots of patches..

They include:

 - objtool validation of jump_label/static_cpu_has

   Allows asserting that the code block following a jump_label/static_cpu_has
   is indeed unconditional. Ensures GCC doesn't generate particularly stupid
   code which would re-insert a dynamic test.

 - objtool validation of retpoline

   Looks for indirect JMP/CALL sites when build with a retpoline enabled
   compiler. Has already spotted a bunch of sites that need fixing, see
   below.

 - makes x86 hard rely on asm-goto to ensure we can indeed use static_cpu_has
   to avoid dynamic branches (and thus speculation).

 - The IBRS/IBPB patches from Thomas that use static_cpu_has()

   These hard rely on the above; we must not speculate across the IBRS/IBPB
   MSR writes otherwise that would totally defeat the point. Prior patches had
   LFENCE crud in the else-clause, which then makes the primitives
   unconditionally expensive.

 - Rebased the IBRS/IBPB-KVM patches from Ashok on top

 - Random odd fixes for various things encountered while doing the above.


Please have a look and sorry for this many patches.

---

Output of a x86_64-allmodconfig -KCOV -KASAN build:

arch/x86/entry/.tmp_entry_64.o: warning: objtool: .entry.text+0x1cb2: indirect 
call found in RETPOLINE build
arch/x86/entry/.tmp_entry_64.o: warning: objtool: .entry.text+0x1cc7: indirect 
call found in RETPOLINE build
arch/x86/hyperv/.tmp_mmu.o: warning: objtool: hyperv_flush_tlb_others()+0x30c: 
indirect call found in RETPOLINE build
arch/x86/hyperv/.tmp_mmu.o: warning: objtool: hyperv_flush_tlb_others()+0x3b0: 
indirect call found in RETPOLINE build
arch/x86/hyperv/.tmp_mmu.o: warning: objtool: 
hyperv_flush_tlb_others_ex()+0x3a1: indirect call found in RETPOLINE build
arch/x86/hyperv/.tmp_mmu.o: warning: objtool: 
hyperv_flush_tlb_others_ex()+0x45c: indirect call found in RETPOLINE build
arch/x86/xen/.tmp_multicalls.o: warning: objtool: xen_mc_flush()+0x1da: 
indirect call found in RETPOLINE build
arch/x86/kvm/.tmp_emulate.o: warning: objtool: fastop()+0x54: indirect call 
found in RETPOLINE build
arch/x86/kvm/.tmp_emulate.o: warning: objtool: em_loop()+0xcc: indirect call 
found in RETPOLINE build
arch/x86/kvm/.tmp_emulate.o: warning: objtool: x86_emulate_insn()+0xbd6: 
indirect call found in RETPOLINE build
arch/x86/kvm/.tmp_emulate.o: warning: objtool: x86_emulate_insn()+0xc1a: 
indirect call found in RETPOLINE build
arch/x86/kvm/.tmp_emulate.o: warning: objtool: x86_emulate_insn()+0xc66: 
indirect call found in RETPOLINE build
arch/x86/kvm/.tmp_vmx.o: warning: objtool: vmx_handle_external_intr()+0x50: 
indirect call found in RETPOLINE build
arch/x86/mm/.tmp_mem_encrypt_boot.o: warning: objtool: 
sme_encrypt_execute()+0x48: indirect call found in RETPOLINE build
drivers/hv/.tmp_hv.o: warning: objtool: hv_post_message()+0x72: indirect call 
found in RETPOLINE build
drivers/hv/.tmp_connection.o: warning: objtool: vmbus_set_event()+0x33: 
indirect call found in RETPOLINE build
drivers/pci/host/.tmp_pci-hyperv.o: warning: objtool: hv_irq_unmask()+0x22b: 
indirect call found in RETPOLINE build
drivers/xen/.tmp_privcmd.o: warning: objtool: privcmd_ioctl()+0xcf: indirect 
call found in RETPOLINE build
drivers/watchdog/.tmp_hpwdt.o: warning: objtool: .text+0x24: indirect call 
found in RETPOLINE build

[PATCH 03/35] x86: Reindent _static_cpu_has

[Peter Zijlstra]

Because its daft..

Cc: Josh Poimboeuf 
Cc: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Signed-off-by: Peter Zijlstra (Intel) 
---
 arch/x86/include/asm/cpufeature.h |   78 +++---
 1 file changed, 39 insertions(+), 39 deletions(-)

--- a/arch/x86/include/asm/cpufeature.h
+++ b/arch/x86/include/asm/cpufeature.h
@@ -145,45 +145,45 @@ extern void clear_cpu_cap(struct cpuinfo
  */
 static __always_inline __pure bool _static_cpu_has(u16 bit)
 {
-   asm_volatile_goto("1: jmp 6f\n"
-"2:\n"
-".skip -(((5f-4f) - (2b-1b)) > 0) * "
-"((5f-4f) - (2b-1b)),0x90\n"
-"3:\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n"  /* src offset */
-" .long 4f - .\n"  /* repl offset */
-" .word %P1\n" /* always replace */
-" .byte 3b - 1b\n" /* src len */
-" .byte 5f - 4f\n" /* repl len */
-" .byte 3b - 2b\n" /* pad len */
-".previous\n"
-".section .altinstr_replacement,\"ax\"\n"
-"4: jmp %l[t_no]\n"
-"5:\n"
-".previous\n"
-".section .altinstructions,\"a\"\n"
-" .long 1b - .\n"  /* src offset */
-" .long 0\n"   /* no replacement */
-" .word %P0\n" /* feature bit */
-" .byte 3b - 1b\n" /* src len */
-" .byte 0\n"   /* repl len */
-" .byte 0\n"   /* pad len */
-".previous\n"
-".section .altinstr_aux,\"ax\"\n"
-"6:\n"
-" testb %[bitnum],%[cap_byte]\n"
-" jnz %l[t_yes]\n"
-" jmp %l[t_no]\n"
-".previous\n"
-: : "i" (bit), "i" (X86_FEATURE_ALWAYS),
-[bitnum] "i" (1 << (bit & 7)),
-[cap_byte] "m" (((const char 
*)boot_cpu_data.x86_capability)[bit >> 3])
-: : t_yes, t_no);
-   t_yes:
-   return true;
-   t_no:
-   return false;
+   asm_volatile_goto("1: jmp 6f\n"
+"2:\n"
+".skip -(((5f-4f) - (2b-1b)) > 0) * "
+"((5f-4f) - (2b-1b)),0x90\n"
+"3:\n"
+".section .altinstructions,\"a\"\n"
+" .long 1b - .\n"  /* src offset */
+" .long 4f - .\n"  /* repl offset */
+" .word %P1\n" /* always replace */
+" .byte 3b - 1b\n" /* src len */
+" .byte 5f - 4f\n" /* repl len */
+" .byte 3b - 2b\n" /* pad len */
+".previous\n"
+".section .altinstr_replacement,\"ax\"\n"
+"4: jmp %l[t_no]\n"
+"5:\n"
+".previous\n"
+".section .altinstructions,\"a\"\n"
+" .long 1b - .\n"  /* src offset */
+" .long 0\n"   /* no replacement */
+" .word %P0\n" /* feature bit */
+" .byte 3b - 1b\n" /* src len */
+" .byte 0\n"   /* repl len */
+" .byte 0\n"   /* pad len */
+".previous\n"
+".section .altinstr_aux,\"ax\"\n"
+"6:\n"
+" testb %[bitnum],%[cap_byte]\n"
+" jnz %l[t_yes]\n"
+" jmp %l[t_no]\n"
+".previous\n"
+: : "i" (bit), "i" (X86_FEATURE_ALWAYS),
+[bitnum] "i" (1 << (bit & 7)),
+[cap_byte] "m" (((const char 
*)boot_cpu_data.x86_capability)[bit >> 3])
+: : t_yes, t_no);
+t_yes:
+   return true;
+t_no:
+   return false;
 }
 
 #define static_cpu_has(bit)\

[PATCH 17/35] objtool: Even more complex static block checks

[Peter Zijlstra]

I've observed GCC transform:

  f()
  {
  if (!static_branch_unlikely())
  return;

  static_assert();
  A;
  }

  g()
  {
  f();
  }

Into:

  f()
  {
  static_assert();
  A;
  }

  g()
  {
  if (static_branch_unlikely())
  f();
  }

Which results in the assertion landing at f+0. The transformation is
valid and useful; it avoids a pointless CALL+RET sequence, so we'll
have to teach objtool how to deal with this.

Do this by marking all CALL destinations with static_call when called
from a static_block and non_static_call when called outside a
static_block. This allows us to identify functions called exclusively
from a static_block and start them with a static_block.

Signed-off-by: Peter Zijlstra (Intel) 
---
 tools/objtool/check.c |   81 +-
 tools/objtool/elf.h   |1 
 2 files changed, 61 insertions(+), 21 deletions(-)

--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1207,36 +1207,75 @@ static int read_retpoline_hints(struct o
return 0;
 }
 
+static bool __grow_static_block(struct objtool_file *file,
+   struct instruction *insn, bool ign_bt)
+{
+   /* if a jump can come in here, terminate */
+   if (insn->branch_target && !ign_bt)
+   return false;
+
+   switch (insn->type) {
+   case INSN_JUMP_UNCONDITIONAL:
+   /* mark this instruction, terminate this section */
+   insn->static_jump_dest = true;
+   return false;
+
+   /* these disturb unconditional code flow, terminate */
+   case INSN_JUMP_CONDITIONAL:
+   case INSN_JUMP_DYNAMIC:
+   case INSN_RETURN:
+   case INSN_BUG:
+   return false;
+
+   /* these return right back and don't disturb the code flow */
+   case INSN_CALL:
+   case INSN_CALL_DYNAMIC:
+   break;
+   }
+
+   /* mark this insn, and continue the section */
+   insn->static_jump_dest = true;
+   return true;
+}
+
 static int grow_static_blocks(struct objtool_file *file)
 {
-   struct instruction *insn;
bool static_block = false;
+   struct symbol *func, *tmp;
+   struct instruction *insn;
+   struct section *sec;
 
for_each_insn(file, insn) {
-   if (!static_block && !insn->static_jump_dest)
-   continue;
+   if (static_block || insn->static_jump_dest)
+   static_block = __grow_static_block(file, insn, 
!static_block);
 
-   if (insn->static_jump_dest) {
-   static_block = true;
-   continue;
+   if (insn->type == INSN_CALL) {
+   func = insn->call_dest;
+   if (!func)
+   continue;
+
+   if (static_block)
+   func->static_call = true;
+   else
+   func->non_static_call = true;
}
+   }
 
-   if (insn->branch_target) {
-   static_block = false;
-   continue;
-   } else switch (insn->type) {
-   case INSN_JUMP_CONDITIONAL:
-   case INSN_JUMP_UNCONDITIONAL:
-   case INSN_JUMP_DYNAMIC:
-   case INSN_CALL:
-   case INSN_CALL_DYNAMIC:
-   case INSN_RETURN:
-   case INSN_BUG:
-   static_block = false;
-   continue;
+   for_each_sec(file, sec) {
+   list_for_each_entry_safe(func, tmp, >symbol_list, list) {
+   if (!func->static_call)
+   continue;
+
+   if (func->non_static_call)
+   continue;
+
+   /* static && !non_static -- only static callers */
+
+   func_for_each_insn(file, func, insn) {
+   if (!__grow_static_block(file, insn, false))
+   break;
+   }
}
-
-   insn->static_jump_dest = static_block;
}
 
return 0;
--- a/tools/objtool/elf.h
+++ b/tools/objtool/elf.h
@@ -61,6 +61,7 @@ struct symbol {
unsigned char bind, type;
unsigned long offset;
unsigned int len;
+   bool static_call, non_static_call;
 };
 
 struct rela {

[PATCH 06/35] objtool: Implement base jump_assert support

[Peter Zijlstra]

Implement a jump_label assertion that asserts that the code location
is indeed only reachable through a static_branch. Because if GCC is
absolutely retaded it could generate code like:

xor rax,rax
NOP/JMP 1f
mov $1, rax
1:
test rax,rax
jz 2f

2:

instead of the sensible:

NOP/JMP 1f

1:

This implements objtool infrastructure for ensuring the code ends up
sane, since we'll rely on that for correctness and security.

We tag the instructions after the static branch with static_jump_dest=true;
that is the instruction after the NOP and the instruction at the
JMP+disp site.

Then, when we read the .discard.jump_assert section, we assert that
each entry points to an instruction that has static_jump_dest set.

With this we can assert that the code emitted for the if statement
ends up at the static jump location and nothing untowards happened.

Cc: Borislav Petkov 
Cc: Thomas Gleixner 
Cc: Josh Poimboeuf 
Signed-off-by: Peter Zijlstra (Intel) 
---
 tools/objtool/check.c |   70 --
 tools/objtool/check.h |1 
 2 files changed, 69 insertions(+), 2 deletions(-)

--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -687,8 +687,17 @@ static int handle_jump_alt(struct objtoo
   struct instruction *orig_insn,
   struct instruction **new_insn)
 {
-   if (orig_insn->type == INSN_NOP)
+   struct instruction *next_insn = list_next_entry(orig_insn, list);
+
+   if (orig_insn->type == INSN_NOP) {
+   /*
+* If orig_insn is a NOP, then new_insn is the branch target
+* for when it would've been a JMP.
+*/
+   next_insn->static_jump_dest = true;
+   (*new_insn)->static_jump_dest = true;
return 0;
+   }
 
if (orig_insn->type != INSN_JUMP_UNCONDITIONAL) {
WARN_FUNC("unsupported instruction at jump label",
@@ -696,7 +705,16 @@ static int handle_jump_alt(struct objtoo
return -1;
}
 
-   *new_insn = list_next_entry(orig_insn, list);
+   /*
+* Otherwise, orig_insn is a JMP and it will have orig_insn->jump_dest.
+* In this case we'll effectively NOP the alt by pointing new_insn at
+* next_insn.
+*/
+   orig_insn->jump_dest->static_jump_dest = true;
+   next_insn->static_jump_dest = true;
+
+   *new_insn = next_insn;
+
return 0;
 }
 
@@ -1067,6 +1085,50 @@ static int read_unwind_hints(struct objt
return 0;
 }
 
+static int assert_static_jumps(struct objtool_file *file)
+{
+   struct section *sec, *relasec;
+   struct instruction *insn;
+   struct rela *rela;
+   int i;
+
+   sec = find_section_by_name(file->elf, ".discard.jump_assert");
+   if (!sec)
+   return 0;
+
+   relasec = sec->rela;
+   if (!relasec) {
+   WARN("missing .rela.discard.jump_assert section");
+   return -1;
+   }
+
+   if (sec->len % sizeof(unsigned long)) {
+   WARN("jump_assert size mismatch: %d %ld", sec->len, 
sizeof(unsigned long));
+   return -1;
+   }
+
+   for (i = 0; i < sec->len / sizeof(unsigned long); i++) {
+   rela = find_rela_by_dest(sec, i * sizeof(unsigned long));
+   if (!rela) {
+   WARN("can't find rela for jump_assert[%d]", i);
+   return -1;
+   }
+
+   insn = find_insn(file, rela->sym->sec, rela->addend);
+   if (!insn) {
+   WARN("can't find insn for jump_assert[%d]", i);
+   return -1;
+   }
+
+   if (!insn->static_jump_dest) {
+   WARN_FUNC("static assert FAIL", insn->sec, 
insn->offset);
+   return -1;
+   }
+   }
+
+   return 0;
+}
+
 static int decode_sections(struct objtool_file *file)
 {
int ret;
@@ -2000,6 +2062,10 @@ int check(const char *_objname, bool _no
goto out;
warnings += ret;
 
+   ret = assert_static_jumps();
+   if (ret < 0)
+   return ret;
+
if (list_empty(_list))
goto out;
 
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -45,6 +45,7 @@ struct instruction {
unsigned char type;
unsigned long immediate;
bool alt_group, visited, dead_end, ignore, hint, save, restore, 
ignore_alts;
+   bool static_jump_dest;
struct symbol *call_dest;
struct instruction *jump_dest;
struct list_head alts;