Re: [PATCH v2] arm64: dts: ls1028a: Fix CPU idle fail.

[Shawn Guo]

On Fri, May 17, 2019 at 12:57:53PM +0800, Ran Wang wrote:
> PSCI spec define 1st parameter's bit 16 of function CPU_SUSPEND to
> indicate CPU State Type: 0 for standby, 1 for power down. In this
> case, we want to select standby for CPU idle feature. But current
> setting wrongly select power down and cause CPU SUSPEND fail every
> time. Need this fix.
> 
> Fixes: 8897f3255c9c ("arm64: dts: Add support for NXP LS1028A SoC")
> Signed-off-by: Ran Wang 

Applied, thanks.

Re: [PATCH 01/11] perf intel-pt: Add new packets for PEBS via PT

[Adrian Hunter]

On 12/06/19 3:09 AM, Arnaldo Carvalho de Melo wrote:
> Em Mon, Jun 10, 2019 at 10:27:53AM +0300, Adrian Hunter escreveu:
>> Add 3 new packets to supports PEBS via PT, namely Block Begin Packet (BBP),
>> Block Item Packet (BIP) and Block End Packet (BEP). PEBS data is encoded
>> into multiple BIP packets that come between BBP and BEP. The BEP packet
>> might be associated with a FUP packet. That is indicated by using a
>> separate packet type (INTEL_PT_BEP_IP) similar to other packets types with
>> the _IP suffix.
>>
>> Refer to the Intel SDM for more information about PEBS via PT.
> 
> In these cases would be nice to provide an URL and page number, for
> convenience.

Intel SDM:

https://software.intel.com/en-us/articles/intel-sdm

May 2019 version: Vol. 3B 18.5.5.2 PEBS output to Intel® Processor Trace

> 
> - Arnaldo
>  
>> Decoding of BIP packets conflicts with single-byte TNT packets. Since BIP
>> packets only occur in the context of a block (i.e. between BBP and BEP),
>> that context must be recorded and passed to the packet decoder.
>>
>> Signed-off-by: Adrian Hunter 
>> ---
>>  .../util/intel-pt-decoder/intel-pt-decoder.c  |  38 -
>>  .../intel-pt-decoder/intel-pt-pkt-decoder.c   | 140 +-
>>  .../intel-pt-decoder/intel-pt-pkt-decoder.h   |  21 ++-
>>  tools/perf/util/intel-pt.c|   3 +-
>>  4 files changed, 193 insertions(+), 9 deletions(-)
>>
>> diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c 
>> b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
>> index 9eb778f9c911..44218f9cf16a 100644
>> --- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
>> +++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
>> @@ -140,6 +140,7 @@ struct intel_pt_decoder {
>>  int mtc_shift;
>>  struct intel_pt_stack stack;
>>  enum intel_pt_pkt_state pkt_state;
>> +enum intel_pt_pkt_ctx pkt_ctx;
>>  struct intel_pt_pkt packet;
>>  struct intel_pt_pkt tnt;
>>  int pkt_step;
>> @@ -558,7 +559,7 @@ static int intel_pt_get_split_packet(struct 
>> intel_pt_decoder *decoder)
>>  memcpy(buf + len, decoder->buf, n);
>>  len += n;
>>  
>> -ret = intel_pt_get_packet(buf, len, >packet);
>> +ret = intel_pt_get_packet(buf, len, >packet, 
>> >pkt_ctx);
>>  if (ret < (int)old_len) {
>>  decoder->next_buf = decoder->buf;
>>  decoder->next_len = decoder->len;
>> @@ -593,6 +594,7 @@ static int intel_pt_pkt_lookahead(struct 
>> intel_pt_decoder *decoder,
>>  {
>>  struct intel_pt_pkt_info pkt_info;
>>  const unsigned char *buf = decoder->buf;
>> +enum intel_pt_pkt_ctx pkt_ctx = decoder->pkt_ctx;
>>  size_t len = decoder->len;
>>  int ret;
>>  
>> @@ -611,7 +613,8 @@ static int intel_pt_pkt_lookahead(struct 
>> intel_pt_decoder *decoder,
>>  if (!len)
>>  return INTEL_PT_NEED_MORE_BYTES;
>>  
>> -ret = intel_pt_get_packet(buf, len, _info.packet);
>> +ret = intel_pt_get_packet(buf, len, _info.packet,
>> +  _ctx);
>>  if (!ret)
>>  return INTEL_PT_NEED_MORE_BYTES;
>>  if (ret < 0)
>> @@ -686,6 +689,10 @@ static int intel_pt_calc_cyc_cb(struct 
>> intel_pt_pkt_info *pkt_info)
>>  case INTEL_PT_MNT:
>>  case INTEL_PT_PTWRITE:
>>  case INTEL_PT_PTWRITE_IP:
>> +case INTEL_PT_BBP:
>> +case INTEL_PT_BIP:
>> +case INTEL_PT_BEP:
>> +case INTEL_PT_BEP_IP:
>>  return 0;
>>  
>>  case INTEL_PT_MTC:
>> @@ -878,7 +885,7 @@ static int intel_pt_get_next_packet(struct 
>> intel_pt_decoder *decoder)
>>  }
>>  
>>  ret = intel_pt_get_packet(decoder->buf, decoder->len,
>> -  >packet);
>> +  >packet, >pkt_ctx);
>>  if (ret == INTEL_PT_NEED_MORE_BYTES && BITS_PER_LONG == 32 &&
>>  decoder->len < INTEL_PT_PKT_MAX_SZ && !decoder->next_buf) {
>>  ret = intel_pt_get_split_packet(decoder);
>> @@ -1624,6 +1631,10 @@ static int intel_pt_walk_psbend(struct 
>> intel_pt_decoder *decoder)
>>  case INTEL_PT_MWAIT:
>>  case INTEL_PT_PWRE:
>>  case INTEL_PT_PWRX:
>> +case INTEL_PT_BBP:
>> +case INTEL_PT_BIP:
>> +case INTEL_PT_BEP:
>> +case INTEL_PT_BEP_IP:
>>  decoder->have_tma = false;
>>  intel_pt_log("ERROR: Unexpected packet\n");
>>  err = -EAGAIN;
>> @@ -1717,6 +1728,10 @@ static int intel_pt_walk_fup_tip(struct 
>> intel_pt_decoder *decoder)
>>  case INTEL_PT_MWAIT:
>>  case INTEL_PT_PWRE:
>>  case INTEL_PT_PWRX:
>> +case INTEL_PT_BBP:
>> +case INTEL_PT_BIP:
>> +case INTEL_PT_BEP:
>> +case 

Re: mmotm 2019-06-11-16-59 uploaded (nf_conntrack_bridge)

[Randy Dunlap]

On 6/11/19 4:59 PM, a...@linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2019-06-11-16-59 has been uploaded to
> 
>http://www.ozlabs.org/~akpm/mmotm/
> 
> mmotm-readme.txt says
> 
> README for mm-of-the-moment:
> 
> http://www.ozlabs.org/~akpm/mmotm/
> 
> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
> more than once a week.
> 
> You will need quilt to apply these patches to the latest Linus release (5.x
> or 5.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
> http://ozlabs.org/~akpm/mmotm/series
> 
> The file broken-out.tar.gz contains two datestamp files: .DATE and
> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
> followed by the base kernel version against which this patch series is to
> be applied.


on i386:

ERROR: "nf_ct_frag6_gather" [net/bridge/netfilter/nf_conntrack_bridge.ko] 
undefined!
ERROR: "br_ip6_fragment" [net/bridge/netfilter/nf_conntrack_bridge.ko] 
undefined!


Full randconfig file is attached.

-- 
~Randy


nfconnbridge.config
Description: application/config

Re: [PATCH v3 7/8] usb: dwc3: qcom: Start USB in 'host mode' on the SDM845

[Lee Jones]

On Tue, 11 Jun 2019, Bjorn Andersson wrote:

> On Mon 10 Jun 01:42 PDT 2019, Lee Jones wrote:
> 
> > When booting with Device Tree, the current default boot configuration
> > table option, the request to boot via 'host mode' comes from the
> > 'dr_mode' property.
> 
> As I said in my previous review, the default mode for SDM845 is OTG. For
> the MTP specifically we specify the default mode to be peripheral (was
> host).
> 
> 
> The remaining thing that worries me with this patch is that I do expect
> that at least one of the USB-C ports is OTG. But I am not able to
> conclude anything regarding this and host-only is a good default for
> this type of device, so I suggest that we merge this.

Right.  So one thing to consider is that Qualcomm Mobile Dept. do not
use ACPI for Linux, so this patch-set only affects the Laptop
form factor devices, where 'host' is the expected mode.

> Reviewed-by: Bjorn Andersson 

Thanks for taking the time to review this Bjorn.

Hopefully we can get Felipe's attention soon.

Felipe,

One thing to think about when taking Bjorn's Reviewed-by into
consideration; although we both work for Linaro, we actually operate
in different teams.  Bjorn is on the Qualcomm Landing Team, and as an
ex-Qualcomm employee he is in an excellent position to review these
patches, thus his Review should carry more weight than the usual
co-worker review IMHO.

TIA.

> > A property of the same name can be used inside
> > ACPI tables too.  However it is missing from the SDM845's ACPI tables
> > so we have to supply this information using Platform Device Properties
> > instead.
> > 
> > This does not change the behaviour of any currently supported devices.
> > The property is only set on ACPI enabled platforms, thus for H/W
> > booting DT, unless a 'dr_mode' property is present, the default is
> > still OTG (On-The-Go) as per [0].  Any new ACPI devices added will
> > also be able to over-ride this implementation by providing a 'dr_mode'
> > property in their ACPI tables.  In cases where 'dr_mode' is omitted
> > from the tables AND 'host mode' should not be the default (very
> > unlikely), then we will have to add some way of choosing between them
> > at run time - most likely by ACPI HID.
> > 
> > [0] Documentation/devicetree/bindings/usb/generic.txt
> > 
> > Signed-off-by: Lee Jones 
> > ---
> >  drivers/usb/dwc3/dwc3-qcom.c | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/drivers/usb/dwc3/dwc3-qcom.c b/drivers/usb/dwc3/dwc3-qcom.c
> > index 1e1f12b7991d..55ba04254e38 100644
> > --- a/drivers/usb/dwc3/dwc3-qcom.c
> > +++ b/drivers/usb/dwc3/dwc3-qcom.c
> > @@ -444,6 +444,11 @@ static int dwc3_qcom_clk_init(struct dwc3_qcom *qcom, 
> > int count)
> > return 0;
> >  }
> >  
> > +static const struct property_entry dwc3_qcom_acpi_properties[] = {
> > +   PROPERTY_ENTRY_STRING("dr_mode", "host"),
> > +   {}
> > +};
> > +
> >  static int dwc3_qcom_acpi_register_core(struct platform_device *pdev)
> >  {
> > struct dwc3_qcom*qcom = platform_get_drvdata(pdev);
> > @@ -488,6 +493,13 @@ static int dwc3_qcom_acpi_register_core(struct 
> > platform_device *pdev)
> > goto out;
> > }
> >  
> > +   ret = platform_device_add_properties(qcom->dwc3,
> > +dwc3_qcom_acpi_properties);
> > +   if (ret < 0) {
> > +   dev_err(>dev, "failed to add properties\n");
> > +   goto out;
> > +   }
> > +
> > ret = platform_device_add(qcom->dwc3);
> > if (ret)
> > dev_err(>dev, "failed to add device\n");

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

[PATCH 2/5] dt-bindings: usb: mtu3: support force_vbus mode

[Chunfeng Yun]

Add a new property to indicate that the controller doesn't support Vbus
detection due to non-exist Vbus PIN, and the driver should set force_vbus
state for device mode

Signed-off-by: Chunfeng Yun 
---
 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt 
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index 5d740e9d4525..c13cc8642154 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -52,6 +52,8 @@ Optional properties:
- 2 : used by mt2712 etc
  - mediatek,u3p-dis-msk : mask to disable u3ports, bit0 for u3port0,
bit1 for u3port1, ... etc;
+ - mediatek,force-vbus : boolean, indicates that the controller doesn't support
+   Vbus detection due to non-exist Vbus PIN.
 
 additionally the properties from usb-hcd.txt (in the current directory) are
 supported.
-- 
2.21.0

[PATCH 1/5] dt-bindings: usb: mtu3: fix typo of DMA clock name

[Chunfeng Yun]

Fix typo of dma_ck

Signed-off-by: Chunfeng Yun 
---
 Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt 
b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
index 3382b5cb471d..5d740e9d4525 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.txt
@@ -16,7 +16,7 @@ Required properties:
entry in clock-names
  - clock-names : must contain "sys_ck" for clock of controller,
the following clocks are optional:
-   "ref_ck", "mcu_ck" and "dam_ck";
+   "ref_ck", "mcu_ck" and "dma_ck";
  - phys : see usb-hcd.txt in the current directory
  - dr_mode : should be one of "host", "peripheral" or "otg",
refer to usb/generic.txt
-- 
2.21.0

[PATCH 3/5] dt-bindings: usb: mtk-xhci: add an optional xhci_ck clock

[Chunfeng Yun]

Add a new optional clock xhci_ck

Signed-off-by: Chunfeng Yun 
---
 Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt 
b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
index 266c2d917a28..91c0704b586b 100644
--- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.txt
@@ -29,6 +29,7 @@ Required properties:
"sys_ck": controller clock used by normal mode,
the following ones are optional:
"ref_ck": reference clock used by low power mode etc,
+   "xhci_ck": controller clock,
"mcu_ck": mcu_bus clock for register access,
"dma_ck": dma_bus clock for data transfer by DMA
 
@@ -100,7 +101,7 @@ Required properties:
  - clocks : a list of phandle + clock-specifier pairs, one for each
entry in clock-names
  - clock-names : must contain "sys_ck", and the following ones are optional:
-   "ref_ck", "mcu_ck" and "dma_ck"
+   "ref_ck", "xhci_ck", "mcu_ck" and "dma_ck"
 
 Optional properties:
  - vbus-supply : reference to the VBUS regulator;
-- 
2.21.0

[PATCH 5/5] usb: xhci-mtk: add an optional xhci_ck clock

[Chunfeng Yun]

Some SoCs may have an optional clock xhci_ck (125M or 200M), it
usually uses the same PLL as sys_ck, so support it.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/host/xhci-mtk.c | 13 +
 drivers/usb/host/xhci-mtk.h |  1 +
 2 files changed, 14 insertions(+)

diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
index 026fe18972d3..b18a6baef204 100644
--- a/drivers/usb/host/xhci-mtk.c
+++ b/drivers/usb/host/xhci-mtk.c
@@ -216,6 +216,10 @@ static int xhci_mtk_clks_get(struct xhci_hcd_mtk *mtk)
return PTR_ERR(mtk->sys_clk);
}
 
+   mtk->xhci_clk = devm_clk_get_optional(dev, "xhci_ck");
+   if (IS_ERR(mtk->xhci_clk))
+   return PTR_ERR(mtk->xhci_clk);
+
mtk->ref_clk = devm_clk_get_optional(dev, "ref_ck");
if (IS_ERR(mtk->ref_clk))
return PTR_ERR(mtk->ref_clk);
@@ -244,6 +248,12 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
goto sys_clk_err;
}
 
+   ret = clk_prepare_enable(mtk->xhci_clk);
+   if (ret) {
+   dev_err(mtk->dev, "failed to enable xhci_clk\n");
+   goto xhci_clk_err;
+   }
+
ret = clk_prepare_enable(mtk->mcu_clk);
if (ret) {
dev_err(mtk->dev, "failed to enable mcu_clk\n");
@@ -261,6 +271,8 @@ static int xhci_mtk_clks_enable(struct xhci_hcd_mtk *mtk)
 dma_clk_err:
clk_disable_unprepare(mtk->mcu_clk);
 mcu_clk_err:
+   clk_disable_unprepare(mtk->xhci_clk);
+xhci_clk_err:
clk_disable_unprepare(mtk->sys_clk);
 sys_clk_err:
clk_disable_unprepare(mtk->ref_clk);
@@ -272,6 +284,7 @@ static void xhci_mtk_clks_disable(struct xhci_hcd_mtk *mtk)
 {
clk_disable_unprepare(mtk->dma_clk);
clk_disable_unprepare(mtk->mcu_clk);
+   clk_disable_unprepare(mtk->xhci_clk);
clk_disable_unprepare(mtk->sys_clk);
clk_disable_unprepare(mtk->ref_clk);
 }
diff --git a/drivers/usb/host/xhci-mtk.h b/drivers/usb/host/xhci-mtk.h
index 8be8c5f7ff62..5ac458b7d2e0 100644
--- a/drivers/usb/host/xhci-mtk.h
+++ b/drivers/usb/host/xhci-mtk.h
@@ -139,6 +139,7 @@ struct xhci_hcd_mtk {
struct regulator *vusb33;
struct regulator *vbus;
struct clk *sys_clk;/* sys and mac clock */
+   struct clk *xhci_clk;
struct clk *ref_clk;
struct clk *mcu_clk;
struct clk *dma_clk;
-- 
2.21.0

[PATCH 4/5] usb: mtu3: support force_vbus mode

[Chunfeng Yun]

Some SoCs don't support Vbus detection due to non-exist Vbus PIN,
so software need set force_vbus state when the controller works
as device mode.

Signed-off-by: Chunfeng Yun 
---
 drivers/usb/mtu3/mtu3.h  |  3 +++
 drivers/usb/mtu3/mtu3_core.c |  1 +
 drivers/usb/mtu3/mtu3_dr.c   |  2 ++
 drivers/usb/mtu3/mtu3_host.c |  1 +
 drivers/usb/mtu3/mtu3_plat.c | 23 +++
 5 files changed, 30 insertions(+)

diff --git a/drivers/usb/mtu3/mtu3.h b/drivers/usb/mtu3/mtu3.h
index 76ecf12fdf62..01b0dc9caa3e 100644
--- a/drivers/usb/mtu3/mtu3.h
+++ b/drivers/usb/mtu3/mtu3.h
@@ -231,6 +231,7 @@ struct otg_switch_mtk {
  * @u3p_dis_msk: mask of disabling usb3 ports, for example, bit0==1 to
  * disable u3port0, bit1==1 to disable u3port1,... etc
  * @dbgfs_root: only used when supports manual dual-role switch via debugfs
+ * @force_vbus: without Vbus PIN, SW need set force_vbus state for device
  * @uwk_en: it's true when supports remote wakeup in host mode
  * @uwk: syscon including usb wakeup glue layer between SSUSB IP and SPM
  * @uwk_reg_base: the base address of the wakeup glue layer in @uwk
@@ -257,6 +258,7 @@ struct ssusb_mtk {
int u3_ports;
int u3p_dis_msk;
struct dentry *dbgfs_root;
+   bool force_vbus;
/* usb wakeup for host mode */
bool uwk_en;
struct regmap *uwk;
@@ -415,6 +417,7 @@ static inline void mtu3_clrbits(void __iomem *base, u32 
offset, u32 bits)
 }
 
 int ssusb_check_clocks(struct ssusb_mtk *ssusb, u32 ex_clks);
+void ssusb_set_force_vbus(struct ssusb_mtk *ssusb, bool vbus_on);
 struct usb_request *mtu3_alloc_request(struct usb_ep *ep, gfp_t gfp_flags);
 void mtu3_free_request(struct usb_ep *ep, struct usb_request *req);
 void mtu3_req_complete(struct mtu3_ep *mep,
diff --git a/drivers/usb/mtu3/mtu3_core.c b/drivers/usb/mtu3/mtu3_core.c
index f8bd1d57e795..65aa382ffb85 100644
--- a/drivers/usb/mtu3/mtu3_core.c
+++ b/drivers/usb/mtu3/mtu3_core.c
@@ -604,6 +604,7 @@ static void mtu3_regs_init(struct mtu3 *mtu)
/* enable automatical HWRW from L1 */
mtu3_setbits(mbase, U3D_POWER_MANAGEMENT, LPM_HRWE);
 
+   ssusb_set_force_vbus(mtu->ssusb, true);
/* use new QMU format when HW version >= 0x1003 */
if (mtu->gen2cp)
mtu3_writel(mbase, U3D_QFCR, ~0x0);
diff --git a/drivers/usb/mtu3/mtu3_dr.c b/drivers/usb/mtu3/mtu3_dr.c
index 5fcb71af875a..006c5864ff45 100644
--- a/drivers/usb/mtu3/mtu3_dr.c
+++ b/drivers/usb/mtu3/mtu3_dr.c
@@ -173,8 +173,10 @@ static void ssusb_set_mailbox(struct otg_switch_mtk 
*otg_sx,
case MTU3_VBUS_OFF:
mtu3_stop(mtu);
pm_relax(ssusb->dev);
+   ssusb_set_force_vbus(ssusb, false);
break;
case MTU3_VBUS_VALID:
+   ssusb_set_force_vbus(ssusb, true);
/* avoid suspend when works as device */
pm_stay_awake(ssusb->dev);
mtu3_start(mtu);
diff --git a/drivers/usb/mtu3/mtu3_host.c b/drivers/usb/mtu3/mtu3_host.c
index c871b94f3e6f..7618a0c384f9 100644
--- a/drivers/usb/mtu3/mtu3_host.c
+++ b/drivers/usb/mtu3/mtu3_host.c
@@ -205,6 +205,7 @@ static void ssusb_host_setup(struct ssusb_mtk *ssusb)
ssusb_set_force_mode(ssusb, MTU3_DR_FORCE_HOST);
 
/* if port0 supports dual-role, works as host mode by default */
+   ssusb_set_force_vbus(ssusb, false);
ssusb_set_vbus(>otg_switch, 1);
 }
 
diff --git a/drivers/usb/mtu3/mtu3_plat.c b/drivers/usb/mtu3/mtu3_plat.c
index fd0f6c5dfbc1..e9d313e92fc3 100644
--- a/drivers/usb/mtu3/mtu3_plat.c
+++ b/drivers/usb/mtu3/mtu3_plat.c
@@ -45,6 +45,27 @@ int ssusb_check_clocks(struct ssusb_mtk *ssusb, u32 ex_clks)
return 0;
 }
 
+void ssusb_set_force_vbus(struct ssusb_mtk *ssusb, bool vbus_on)
+{
+   u32 u2ctl;
+   u32 misc;
+
+   if (!ssusb->force_vbus)
+   return;
+
+   u2ctl = mtu3_readl(ssusb->ippc_base, SSUSB_U2_CTRL(0));
+   misc = mtu3_readl(ssusb->mac_base, U3D_MISC_CTRL);
+   if (vbus_on) {
+   u2ctl &= ~SSUSB_U2_PORT_OTG_SEL;
+   misc |= VBUS_FRC_EN | VBUS_ON;
+   } else {
+   u2ctl |= SSUSB_U2_PORT_OTG_SEL;
+   misc &= ~(VBUS_FRC_EN | VBUS_ON);
+   }
+   mtu3_writel(ssusb->ippc_base, SSUSB_U2_CTRL(0), u2ctl);
+   mtu3_writel(ssusb->mac_base, U3D_MISC_CTRL, misc);
+}
+
 static int ssusb_phy_init(struct ssusb_mtk *ssusb)
 {
int i;
@@ -268,6 +289,8 @@ static int get_ssusb_rscs(struct platform_device *pdev, 
struct ssusb_mtk *ssusb)
if (IS_ERR(ssusb->ippc_base))
return PTR_ERR(ssusb->ippc_base);
 
+   ssusb->force_vbus = of_property_read_bool(node, "mediatek,force-vbus");
+
ssusb->dr_mode = usb_get_dr_mode(dev);
if (ssusb->dr_mode == USB_DR_MODE_UNKNOWN)
ssusb->dr_mode = USB_DR_MODE_OTG;
-- 
2.21.0

Re: [RFC] On the Current Troubles of Mainlining Loongson Platform Drivers

[Maciej W. Rozycki]

On Tue, 11 Jun 2019, Aaro Koskinen wrote:

> However, with your patch the "nobody cared" is never reached so all is
> good. I tried 10 boots with the patch and all were successful. Without
> the patch 8 out of 10 failed with the "nobody cared" warning.

 I wouldn't call it "good", just less obvious or painful.  This is still 
causing wasted CPU cycles that are used for taking the phantom interrupts.

 There is clearly a completion barrier missing somewhere that causes the 
interrupt request to linger beyond the point interrupts are reenabled at 
the CPU.

 One way to attempt to narrow it down might be taking a backtrace from 
where IRQ 14 is found to be spurious.  This would indicate the offending 
interrupt unmask action.  E.g. I see no explicit completion barrier 
between the final `outb' in `mask_and_ack_8259A' and the following call to 
`raw_spin_unlock_irqrestore', which are obviously otherwise unordered WRT 
each other (because `outb' is I/O or MMIO and `raw_spin_unlock_irqrestore' 
is contained within the CPU on UP).  I can see provisions however for 
issuing an architecture-specific barrier in `do_raw_spin_unlock', which is 
the workhorse for `raw_spin_unlock_irqrestore', so maybe this is the place 
to look into?

 Also how's IRQ 14 registered as indicated by /proc/interrupts?

  Maciej

Re: [PATCH v2 8/8] habanalabs: enable 64-bit DMA mask in POWER9

[Oliver O'Halloran]

On Wed, Jun 12, 2019 at 8:54 AM Benjamin Herrenschmidt
 wrote:
>
> On Tue, 2019-06-11 at 20:22 +0300, Oded Gabbay wrote:
> >
> > > So, to summarize:
> > > If I call pci_set_dma_mask with 48, then it fails on POWER9. However,
> > > in runtime, I don't know if its POWER9 or not, so upon failure I will
> > > call it again with 32, which makes our device pretty much unusable.
> > > If I call pci_set_dma_mask with 64, and do the dedicated configuration
> > > in Goya's PCIe controller, then it won't work on x86-64, because bit
> > > 59 will be set and the host won't like it (I checked it). In addition,
> > > I might get addresses above 50 bits, which my device can't generate.
> > >
> > > I hope this makes things more clear. Now, please explain to me how I
> > > can call pci_set_dma_mask without any regard to whether I run on
> > > x86-64 or POWER9, considering what I wrote above ?
> > >
> > > Thanks,
> > > Oded
> >
> > Adding ppc mailing list.
>
> You can't. Your device is broken. Devices that don't support DMAing to
> the full 64-bit deserve to be added to the trash pile.
>
> As a result, getting it to work will require hacks. Some GPUs have
> similar issues and require similar hacks, it's unfortunate.
>
> Added a couple of guys on CC who might be able to help get those hacks
> right.

> It's still very fishy .. the idea is to detect the case where setting a
> 64-bit mask will give your system memory mapped at a fixed high address
> (1 << 59 in our case) and program that in your chip in the "Fixed high
> bits" register that you seem to have (also make sure it doesn't affect
> MSIs or it will break them).

Judging from the patch (https://lkml.org/lkml/2019/6/11/59) this is
what they're doing.

Also, are you sure about the MSI thing? The IODA3 spec says the only
important bits for a 64bit MSI are bits 61:60 (to hit the window) and
the lower bits that determine what IVE to use. Everything in between
is ignored so ORing in bit 59 shouldn't break anything.

> This will only work as long as all of the system memory can be
> addressed at an offset from that fixed address that itself fits your
> device addressing capabilities (50 bits in this case). It may or may
> not be the case but there's no way to check since the DMA mask logic
> won't really apply.
>
> You might want to consider fixing your HW in the next iteration... This
> is going to bite you when x86 increases the max physical memory for
> example, or on other architectures.

Yes, do this. The easiest way to avoid this sort of wierd hack is to
just design the PCIe interface to the spec in the first place.

madvise() flags for not to sync dirty pages to the disk in shared mapping

[dharmendra hans]

Hi,
I was searching for some  madvise() flag options which allow my
application to have choice of not syncing dirty pages created through
shared mmap() to the disk. Issue is that currently dirty pages created
by the application will be synced to the disk and there is no way
application can avoid that except MADV_REMOVE. But MADV_REMOVE punches
the hole in the file and it takes a lot of time if mapping size was
big, therefore one wants to avoid this option as it delays the further
state change in application.

So  one seems to have two issue.
1) Application is forced to wait during munmap() as dirty pages are synced.
2) if one kill the application process, it lands in process defunct
state for long time and it seems pages which were created by
application are being synced to the disk.

MADV_REMOVE seems to solve it but it is really slow due to file
truncation on mapped file.
What is desired is that application should be allowed choice of no
dirty pages sync without creating hole in the mapped file.

-Dharmendra

Re: Coccinelle: api: add devm_platform_ioremap_resource script

[Julia Lawall]

On Tue, 11 Jun 2019, Enrico Weigelt, metux IT consult wrote:

> On 09.06.19 10:55, Markus Elfring wrote:
>
> 
>
> >> But there is not usually any interesting formatting on the left side of an
> >> assignment (ie typically no newlines or comments).
> >
> > Is there any need to trigger additional source code reformatting?
> >
> >> I can see no purpose to factorizing the right parenthesis.
> >
> > These characters at the end of such a function call should be kept 
> > unchanged.
>
> Agreed. OTOH, we all know that spatch results still need to be carefully
> checked. I suspect trying to teach it all the formatting rules of the
> kernel isn't an easy task.
>
> > The flag “IORESOURCE_MEM” is passed as the second parameter for the call
> > of the function “platform_get_resource” in this refactoring.
>
> In that particular case, we maybe should consider separate inline
> helpers instead of passing this is a parameter.
>
> Maybe it would even be more efficient to have completely separate
> versions of devm_platform_ioremap_resource(), so we don't even have
> to pass that parameter on stack.

I'm lost as to why this discussion suddenly appeared.  What problem is
actually being discussed?

julia

[PATCH+DISCUSSION] irqchip: armada-370-xp: Remove redundant ops assignment

[Benjamin Herrenschmidt]

pci_msi_create_irq_domain -> pci_msi_domain_update_chip_ops will
set those two already since the driver sets MSI_FLAG_USE_DEF_CHIP_OPS

Signed-off-by: Benjamin Herrenschmidt 
---

[UNTESTED]

Just something I noticed while browsing through those drivers in
search of ways to factor some of the code.

That leads to a question here:

Some MSI drivers such as this one (or any using the defaults mask/unmask
provided by drivers/pci/msi.c) only call the PCI MSI mask/unmask functions.

Some other drivers call those PCI function but *also* call the parent
mask/unmask (giv-v2m for example) which generally is the inner domain
which just itself forwards to its own parent.

Is there any preference for doing it one way or the other ? I can see
that in cases where the device doesn't support MSI masking, calling the
parent could be useful but we don't know that at the moment in the
corresponding code.

It feels like something we should consolidate (and remove code from
drivers). For example, the defaults in drivers/pci/msi.c could always
call the parent if it exists and has a mask/unmask callback.

Opinions ? I'm happy to produce patches once we agree...

diff --git a/drivers/irqchip/irq-armada-370-xp.c 
b/drivers/irqchip/irq-armada-370-xp.c
index c9bdc5221b82..911230f28e2d 100644
--- a/drivers/irqchip/irq-armada-370-xp.c
+++ b/drivers/irqchip/irq-armada-370-xp.c
@@ -197,8 +197,6 @@ static void armada_370_xp_irq_unmask(struct irq_data *d)
 
 static struct irq_chip armada_370_xp_msi_irq_chip = {
.name = "MPIC MSI",
-   .irq_mask = pci_msi_mask_irq,
-   .irq_unmask = pci_msi_unmask_irq,
 };
 
 static struct msi_domain_info armada_370_xp_msi_domain_info = {

Re: linux-next 20190611: objtool warning

[Guenter Roeck]

On 6/11/19 7:52 PM, Josh Poimboeuf wrote:

On Tue, Jun 11, 2019 at 06:59:22PM -0700, Randy Dunlap wrote:

Hi,

New warning AFAIK:

drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0x11f: sibling call 
from callable instruction with modified stack frame


I'm getting a different warning:

   drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't find 
jump dest instruction at .text+0x93a

But I bet the root cause is the same.

This fixes it for me:

From: Josh Poimboeuf 
Subject: [PATCH] hwmon/smsc47m1: Fix objtool warning caused by undefined 
behavior

Objtool is reporting the following warning:

   drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't find 
jump dest instruction at .text+0x93a

It's apparently caused by

   2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
warnings")

which is somehow convincing GCC to add a jump past the end of the
function:

   793:   45 85 edtest   %r13d,%r13d
   796:   0f 88 9e 01 00 00   js 93a 
   ...
   930:   e9 5e fe ff ff  jmpq   793 
   935:   e8 00 00 00 00  callq  93a 
936: R_X86_64_PLT32 __stack_chk_fail-0x4
   

I suppose this falls under the category of undefined behavior, so we
probably can't call it a GCC bug.  But if the value of "nr" were out of
range somehow then it would start executing random code.  Use a runtime
BUG() assertion to avoid undefined behavior.

Fixes: 2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
warnings")
Reported-by: Randy Dunlap 
Signed-off-by: Josh Poimboeuf 
---
  drivers/hwmon/smsc47m1.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
index 6d366c9cb906..b637836b58a1 100644
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -352,7 +352,7 @@ static ssize_t fan_div_store(struct device *dev,
smsc47m1_write_value(data, SMSC47M2_REG_FANDIV3, tmp);
break;
default:
-   unreachable();
+   BUG();


Sigh. And I wanted to avoid BUG() because this is all just to make
the compiler happy to start with. Oh well. I updated the offending
patch to use BUG().

Guenter


}
  
  	/* Preserve fan min */

Re: [PATCH 4/4] mm: shrinker: make shrinker not depend on memcg kmem

[Yang Shi]

On 6/11/19 7:52 PM, Kirill A. Shutemov wrote:

On Fri, Jun 07, 2019 at 02:07:39PM +0800, Yang Shi wrote:

Currently shrinker is just allocated and can work when memcg kmem is
enabled.  But, THP deferred split shrinker is not slab shrinker, it
doesn't make too much sense to have such shrinker depend on memcg kmem.
It should be able to reclaim THP even though memcg kmem is disabled.

Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker,
i.e. THP deferred split shrinker.  When memcg kmem is disabled, just
such shrinkers can be called in shrinking memcg slab.

Looks like it breaks bisectability. It has to be done before makeing
shrinker memcg-aware, hasn't it?


No, it doesn't break bisectability. But, THP shrinker just can be called 
with kmem charge enabled without this patch.

Re: [PATCH 2/4] mm: thp: make deferred split shrinker memcg aware

[Yang Shi]

On 6/11/19 7:47 PM, Kirill A. Shutemov wrote:

On Fri, Jun 07, 2019 at 02:07:37PM +0800, Yang Shi wrote:

+   /*
+* The THP may be not on LRU at this point, e.g. the old page of
+* NUMA migration.  And PageTransHuge is not enough to distinguish
+* with other compound page, e.g. skb, THP destructor is not used
+* anymore and will be removed, so the compound order sounds like
+* the only choice here.
+*/
+   if (PageTransHuge(page) && compound_order(page) == HPAGE_PMD_ORDER) {

What happens if the page is the same order as THP is not THP? Why removing


It may corrupt the deferred split queue since it is never added into the 
list, but deleted here.



of destructor is required?


Due to the change to free_transhuge_page() (extracted deferred split 
queue manipulation and moved before memcg uncharge since 
page->mem_cgroup is needed), it just calls free_compound_page(). So, it 
sounds pointless to still keep THP specific destructor.


It looks there is not a good way to tell if the compound page is THP in 
free_page path or not, we may keep the destructor just for this?

Re: [PATCH bpf v2] bpf: fix nested bpf tracepoints with per-cpu data

[Andrii Nakryiko]

On Tue, Jun 11, 2019 at 8:48 PM Matt Mullins  wrote:
>
> BPF_PROG_TYPE_RAW_TRACEPOINTs can be executed nested on the same CPU, as
> they do not increment bpf_prog_active while executing.
>
> This enables three levels of nesting, to support
>   - a kprobe or raw tp or perf event,
>   - another one of the above that irq context happens to call, and
>   - another one in nmi context
> (at most one of which may be a kprobe or perf event).
>
> Fixes: 20b9d7ac4852 ("bpf: avoid excessive stack usage for perf_sample_data")
> Signed-off-by: Matt Mullins 
> ---

LGTM, minor nit below.

Acked-by: Andrii Nakryiko 

> v1->v2:
>   * reverse-Christmas-tree-ize the declarations in bpf_perf_event_output
>   * instantiate err more readably
>
> I've done additional testing with the original workload that hit the
> irq+raw-tp reentrancy problem, and as far as I can tell, it's still
> solved with this solution (as opposed to my earlier per-map-element
> version).
>
>  kernel/trace/bpf_trace.c | 100 ---
>  1 file changed, 84 insertions(+), 16 deletions(-)
>
> diff --git a/kernel/trace/bpf_trace.c b/kernel/trace/bpf_trace.c
> index f92d6ad5e080..1c9a4745e596 100644
> --- a/kernel/trace/bpf_trace.c
> +++ b/kernel/trace/bpf_trace.c
> @@ -410,8 +410,6 @@ static const struct bpf_func_proto 
> bpf_perf_event_read_value_proto = {
> .arg4_type  = ARG_CONST_SIZE,
>  };
>
> -static DEFINE_PER_CPU(struct perf_sample_data, bpf_trace_sd);
> -
>  static __always_inline u64
>  __bpf_perf_event_output(struct pt_regs *regs, struct bpf_map *map,
> u64 flags, struct perf_sample_data *sd)
> @@ -442,24 +440,50 @@ __bpf_perf_event_output(struct pt_regs *regs, struct 
> bpf_map *map,
> return perf_event_output(event, sd, regs);
>  }
>
> +/*
> + * Support executing tracepoints in normal, irq, and nmi context that each 
> call
> + * bpf_perf_event_output
> + */
> +struct bpf_trace_sample_data {
> +   struct perf_sample_data sds[3];
> +};
> +
> +static DEFINE_PER_CPU(struct bpf_trace_sample_data, bpf_trace_sds);
> +static DEFINE_PER_CPU(int, bpf_trace_nest_level);
>  BPF_CALL_5(bpf_perf_event_output, struct pt_regs *, regs, struct bpf_map *, 
> map,
>u64, flags, void *, data, u64, size)
>  {
> -   struct perf_sample_data *sd = this_cpu_ptr(_trace_sd);
> +   struct bpf_trace_sample_data *sds = this_cpu_ptr(_trace_sds);
> +   int nest_level = this_cpu_inc_return(bpf_trace_nest_level);
> struct perf_raw_record raw = {
> .frag = {
> .size = size,
> .data = data,
> },
> };
> +   struct perf_sample_data *sd;
> +   int err;
>
> -   if (unlikely(flags & ~(BPF_F_INDEX_MASK)))
> -   return -EINVAL;
> +   if (WARN_ON_ONCE(nest_level > ARRAY_SIZE(sds->sds))) {
> +   err = -EBUSY;
> +   goto out;
> +   }
> +
> +   sd = >sds[nest_level - 1];
> +
> +   if (unlikely(flags & ~(BPF_F_INDEX_MASK))) {
> +   err = -EINVAL;
> +   goto out;
> +   }

Feel free to ignore, but just stylistically, given this check doesn't
depend on sd, I'd move it either to the very top or right after
`nest_level > ARRAY_SIZE(sds->sds)` check, so that all the error
checking is grouped without interspersed assignment.

>
> perf_sample_data_init(sd, 0, 0);
> sd->raw = 
>
> -   return __bpf_perf_event_output(regs, map, flags, sd);
> +   err = __bpf_perf_event_output(regs, map, flags, sd);
> +
> +out:
> +   this_cpu_dec(bpf_trace_nest_level);
> +   return err;
>  }
>
>  static const struct bpf_func_proto bpf_perf_event_output_proto = {
> @@ -822,16 +846,48 @@ pe_prog_func_proto(enum bpf_func_id func_id, const 
> struct bpf_prog *prog)
>  /*
>   * bpf_raw_tp_regs are separate from bpf_pt_regs used from skb/xdp
>   * to avoid potential recursive reuse issue when/if tracepoints are added
> - * inside bpf_*_event_output, bpf_get_stackid and/or bpf_get_stack
> + * inside bpf_*_event_output, bpf_get_stackid and/or bpf_get_stack.
> + *
> + * Since raw tracepoints run despite bpf_prog_active, support concurrent 
> usage
> + * in normal, irq, and nmi context.
>   */
> -static DEFINE_PER_CPU(struct pt_regs, bpf_raw_tp_regs);
> +struct bpf_raw_tp_regs {
> +   struct pt_regs regs[3];
> +};
> +static DEFINE_PER_CPU(struct bpf_raw_tp_regs, bpf_raw_tp_regs);
> +static DEFINE_PER_CPU(int, bpf_raw_tp_nest_level);
> +static struct pt_regs *get_bpf_raw_tp_regs(void)
> +{
> +   struct bpf_raw_tp_regs *tp_regs = this_cpu_ptr(_raw_tp_regs);
> +   int nest_level = this_cpu_inc_return(bpf_raw_tp_nest_level);
> +
> +   if (WARN_ON_ONCE(nest_level > ARRAY_SIZE(tp_regs->regs))) {
> +   this_cpu_dec(bpf_raw_tp_nest_level);
> +   return ERR_PTR(-EBUSY);
> +   }
> +
> +   return _regs->regs[nest_level - 1];
> +}
> +
> +static void put_bpf_raw_tp_regs(void)
> +{

Re: [PATCH] powerpc/32s: fix booting with CONFIG_PPC_EARLY_DEBUG_BOOTX

[Michael Ellerman]

On Mon, 2019-06-03 at 13:00:51 UTC, Christophe Leroy wrote:
> When booting through OF, setup_disp_bat() does nothing because
> disp_BAT are not set. By change, it used to work because BOOTX
> buffer is mapped 1:1 at address 0x8100 by the bootloader, and
> btext_setup_display() sets virt addr same as phys addr.
> 
> But since commit 215b823707ce ("powerpc/32s: set up an early static
> hash table for KASAN."), a temporary page table overrides the
> bootloader mapping.
> 
> This 0x8100 is also problematic with the newly implemented
> Kernel Userspace Access Protection (KUAP) because it is within user
> address space.
> 
> This patch fixes those issues by properly setting disp_BAT through
> a call to btext_prepare_BAT(), allowing setup_disp_bat() to
> properly setup BAT3 for early bootx screen buffer access.
> 
> Reported-by: Mathieu Malaterre 
> Fixes: 215b823707ce ("powerpc/32s: set up an early static hash table for 
> KASAN.")
> Signed-off-by: Christophe Leroy 
> Tested-by: Mathieu Malaterre 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/c21f5a9ed85ca3e914ca11f421677ae9

cheers

Re: [PATCH v3] powerpc: fix kexec failure on book3s/32

[Michael Ellerman]

On Mon, 2019-06-03 at 08:20:28 UTC, Christophe Leroy wrote:
> In the old days, _PAGE_EXEC didn't exist on 6xx aka book3s/32.
> Therefore, allthough __mapin_ram_chunk() was already mapping kernel
> text with PAGE_KERNEL_TEXT and the rest with PAGE_KERNEL, the entire
> memory was executable. Part of the memory (first 512kbytes) was
> mapped with BATs instead of page table, but it was also entirely
> mapped as executable.
> 
> In commit 385e89d5b20f ("powerpc/mm: add exec protection on
> powerpc 603"), we started adding exec protection to some 6xx, namely
> the 603, for pages mapped via pagetables.
> 
> Then, in commit 63b2bc619565 ("powerpc/mm/32s: Use BATs for
> STRICT_KERNEL_RWX"), the exec protection was extended to BAT mapped
> memory, so that really only the kernel text could be executed.
> 
> The problem here is that kexec is based on copying some code into
> upper part of memory then executing it from there in order to install
> a fresh new kernel at its definitive location.
> 
> However, the code is position independant and first part of it is
> just there to deactivate the MMU and jump to the second part. So it
> is possible to run this first part inplace instead of running the
> copy. Once the MMU is off, there is no protection anymore and the
> second part of the code will just run as before.
> 
> Reported-by: Aaro Koskinen 
> Fixes: 63b2bc619565 ("powerpc/mm/32s: Use BATs for STRICT_KERNEL_RWX")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Christophe Leroy 
> Tested-by: Aaro Koskinen 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/6c284228eb356a1ec62a704b4d232971

cheers

Re: [PATCH -next] dmaengine: dw-edma: Fix build error without CONFIG_PCI_MSI

[Vinod Koul]

On 12-06-19, 12:19, YueHaibing wrote:
> If CONFIG_PCI_MSI is not set, building with CONFIG_DW_EDMA
> fails:
> 
> drivers/dma/dw-edma/dw-edma-core.c: In function dw_edma_irq_request:
> drivers/dma/dw-edma/dw-edma-core.c:784:21: error: implicit declaration of 
> function pci_irq_vector; did you mean rcu_irq_enter? 
> [-Werror=implicit-function-declaration]
>err = request_irq(pci_irq_vector(to_pci_dev(dev), 0),
>  ^~

Applied with adding reported by Randy as well, thanks

> 
> Reported-by: Hulk Robot 
> Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
> Signed-off-by: YueHaibing 
> ---
>  drivers/dma/dw-edma/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma/dw-edma/Kconfig b/drivers/dma/dw-edma/Kconfig
> index c0838ce..7ff17b2 100644
> --- a/drivers/dma/dw-edma/Kconfig
> +++ b/drivers/dma/dw-edma/Kconfig
> @@ -2,6 +2,7 @@
>  
>  config DW_EDMA
>   tristate "Synopsys DesignWare eDMA controller driver"
> + depends on PCI && PCI_MSI
>   select DMA_ENGINE
>   select DMA_VIRTUAL_CHANNELS
>   help
> -- 
> 2.7.4
> 

-- 
~Vinod

Re: linux-next: Tree for Jun 11 (drivers/dma/dw-edma/)

[Vinod Koul]

On 11-06-19, 10:30, Randy Dunlap wrote:
> On 6/11/19 2:24 AM, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Changes since 20190607:
> > 
> 
> on x86_64 or i386:
> 
> when CONFIG_PCI is not set/enabled:
> 
> ../drivers/dma/dw-edma/dw-edma-core.c: In function ‘dw_edma_irq_request’:
> ../drivers/dma/dw-edma/dw-edma-core.c:784:3: error: implicit declaration of 
> function ‘pci_irq_vector’ [-Werror=implicit-function-declaration]
>err = request_irq(pci_irq_vector(to_pci_dev(dev), 0),
>^

Thanks for the report, I am applying the fix YueHaibing with your
reported by.

-- 
~Vinod

[PATCH 1/2] staging: rtl8712: Fixed CamelCase lockRxFF0Filter renamed to lock_rx_ff0_filter

[Deepak Mishra]

In process of cleaning up struct _adapter in drv_types.h, lockRxFF0Filter
 is renamed to to lock_rx_ff0_filter to fix a checkpatch reported issue.

Signed-off-by: Deepak Mishra 
---
 drivers/staging/rtl8712/drv_types.h  | 2 +-
 drivers/staging/rtl8712/usb_intf.c   | 2 +-
 drivers/staging/rtl8712/xmit_linux.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index c36a5ef3ee5d..79d10b6fbfda 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -160,7 +160,7 @@ struct _adapter {
int pid; /*process id from UI*/
struct work_struct wkFilterRxFF0;
u8 blnEnableRxFF0Filter;
-   spinlock_t lockRxFF0Filter;
+   spinlock_t lock_rx_ff0_filter;
const struct firmware *fw;
struct usb_interface *pusb_intf;
struct mutex mutex_start;
diff --git a/drivers/staging/rtl8712/usb_intf.c 
b/drivers/staging/rtl8712/usb_intf.c
index 200a271c28e1..d0daae0b8299 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -571,7 +571,7 @@ static int r871xu_drv_init(struct usb_interface *pusb_intf,
/* step 6. Load the firmware asynchronously */
if (rtl871x_load_fw(padapter))
goto error;
-   spin_lock_init(>lockRxFF0Filter);
+   spin_lock_init(>lock_rx_ff0_filter);
mutex_init(>mutex_start);
return 0;
 error:
diff --git a/drivers/staging/rtl8712/xmit_linux.c 
b/drivers/staging/rtl8712/xmit_linux.c
index 223a4eba4bf4..d8307bcc63f5 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -102,9 +102,9 @@ void r8712_SetFilter(struct work_struct *work)
newvalue = oldvalue & 0xfe;
r8712_write8(adapter, 0x117, newvalue);
 
-   spin_lock_irqsave(>lockRxFF0Filter, irqL);
+   spin_lock_irqsave(>lock_rx_ff0_filter, irqL);
adapter->blnEnableRxFF0Filter = 1;
-   spin_unlock_irqrestore(>lockRxFF0Filter, irqL);
+   spin_unlock_irqrestore(>lock_rx_ff0_filter, irqL);
do {
msleep(100);
} while (adapter->blnEnableRxFF0Filter == 1);
-- 
2.19.1

[PATCH 0/2] staging: rtl8712: cleanup struct _adapter

[Deepak Mishra]

In process of cleaning up rtl8712 struct _adapter in drv_types.h I have
fixed the camelcasing of lockRxFF0Filter and wkFilterRxFF0

Deepak Mishra (2):
  staging: rtl8712: Fixed CamelCase lockRxFF0Filter renamed to
lock_rx_ff0_filter
  staging: rtl8712: Fixed CamelCase wkFilterRxFF0 renamed to
wk_filter_rx_ff0

 drivers/staging/rtl8712/drv_types.h| 4 ++--
 drivers/staging/rtl8712/rtl871x_xmit.c | 2 +-
 drivers/staging/rtl8712/usb_intf.c | 2 +-
 drivers/staging/rtl8712/xmit_linux.c   | 6 +++---
 4 files changed, 7 insertions(+), 7 deletions(-)

-- 
2.19.1

[PATCH 2/2] staging: rtl8712: Fixed CamelCase wkFilterRxFF0 renamed to wk_filter_rx_ff0

[Deepak Mishra]

In process of cleaning up struct _adapter in drv_types.h, wkFilterRxFF0
 is renamed to to wk_filter_rx_ff0 to fix a checkpatch reported issue.

Signed-off-by: Deepak Mishra 
---
 drivers/staging/rtl8712/drv_types.h| 2 +-
 drivers/staging/rtl8712/rtl871x_xmit.c | 2 +-
 drivers/staging/rtl8712/xmit_linux.c   | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8712/drv_types.h 
b/drivers/staging/rtl8712/drv_types.h
index 79d10b6fbfda..0c4325073c63 100644
--- a/drivers/staging/rtl8712/drv_types.h
+++ b/drivers/staging/rtl8712/drv_types.h
@@ -158,7 +158,7 @@ struct _adapter {
struct net_device_stats stats;
struct iw_statistics iwstats;
int pid; /*process id from UI*/
-   struct work_struct wkFilterRxFF0;
+   struct work_struct wk_filter_rx_ff0;
u8 blnEnableRxFF0Filter;
spinlock_t lock_rx_ff0_filter;
const struct firmware *fw;
diff --git a/drivers/staging/rtl8712/rtl871x_xmit.c 
b/drivers/staging/rtl8712/rtl871x_xmit.c
index bfd5538a4652..5d63d2721eb6 100644
--- a/drivers/staging/rtl8712/rtl871x_xmit.c
+++ b/drivers/staging/rtl8712/rtl871x_xmit.c
@@ -139,7 +139,7 @@ sint _r8712_init_xmit_priv(struct xmit_priv *pxmitpriv,
pxmitbuf++;
}
pxmitpriv->free_xmitbuf_cnt = NR_XMITBUFF;
-   INIT_WORK(>wkFilterRxFF0, r8712_SetFilter);
+   INIT_WORK(>wk_filter_rx_ff0, r8712_SetFilter);
alloc_hwxmits(padapter);
init_hwxmits(pxmitpriv->hwxmits, pxmitpriv->hwxmit_entry);
tasklet_init(>xmit_tasklet,
diff --git a/drivers/staging/rtl8712/xmit_linux.c 
b/drivers/staging/rtl8712/xmit_linux.c
index d8307bcc63f5..dc03f0d0c85d 100644
--- a/drivers/staging/rtl8712/xmit_linux.c
+++ b/drivers/staging/rtl8712/xmit_linux.c
@@ -94,7 +94,7 @@ void r8712_set_qos(struct pkt_file *ppktfile, struct 
pkt_attrib *pattrib)
 void r8712_SetFilter(struct work_struct *work)
 {
struct _adapter *adapter = container_of(work, struct _adapter,
-   wkFilterRxFF0);
+   wk_filter_rx_ff0);
u8  oldvalue = 0x00, newvalue = 0x00;
unsigned long irqL;
 
-- 
2.19.1

[PATCH v9 4/4] arm64: dts: qcom: sdm845: Add Q6V5 MSS node

[Bjorn Andersson]

From: Sibi Sankar 

This patch adds Q6V5 MSS remoteproc node for SDM845 SoCs.

Reviewed-by: Douglas Anderson 
Reviewed-by: Vinod Koul 
Signed-off-by: Sibi Sankar 
Signed-off-by: Bjorn Andersson 
---

Changes since v8:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c80881309f79..601cfb078bd5 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -1850,6 +1850,64 @@
};
};
 
+   mss_pil: remoteproc@408 {
+   compatible = "qcom,sdm845-mss-pil";
+   reg = <0 0x0408 0 0x408>, <0 0x0418 0 0x48>;
+   reg-names = "qdsp6", "rmb";
+
+   interrupts-extended =
+   < GIC_SPI 266 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 0 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 1 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 2 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 3 IRQ_TYPE_EDGE_RISING>,
+   <_smp2p_in 7 IRQ_TYPE_EDGE_RISING>;
+   interrupt-names = "wdog", "fatal", "ready",
+ "handover", "stop-ack",
+ "shutdown-ack";
+
+   clocks = < GCC_MSS_CFG_AHB_CLK>,
+< GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+< GCC_BOOT_ROM_AHB_CLK>,
+< GCC_MSS_GPLL0_DIV_CLK_SRC>,
+< GCC_MSS_SNOC_AXI_CLK>,
+< GCC_MSS_MFAB_AXIS_CLK>,
+< GCC_PRNG_AHB_CLK>,
+< RPMH_CXO_CLK>;
+   clock-names = "iface", "bus", "mem", "gpll0_mss",
+ "snoc_axi", "mnoc_axi", "prng", "xo";
+
+   qcom,smem-states = <_smp2p_out 0>;
+   qcom,smem-state-names = "stop";
+
+   resets = <_reset AOSS_CC_MSS_RESTART>,
+<_reset PDC_MODEM_SYNC_RESET>;
+   reset-names = "mss_restart", "pdc_reset";
+
+   qcom,halt-regs = <_mutex_regs 0x23000 0x25000 
0x24000>;
+
+   power-domains = <_qmp 2>,
+   < SDM845_CX>,
+   < SDM845_MX>,
+   < SDM845_MSS>;
+   power-domain-names = "load_state", "cx", "mx", "mss";
+
+   mba {
+   memory-region = <_region>;
+   };
+
+   mpss {
+   memory-region = <_region>;
+   };
+
+   glink-edge {
+   interrupts = ;
+   label = "modem";
+   qcom,remote-pid = <1>;
+   mboxes = <_shared 12>;
+   };
+   };
+
gpucc: clock-controller@509 {
compatible = "qcom,sdm845-gpucc";
reg = <0 0x0509 0 0x9000>;
-- 
2.18.0

[PATCH v9 3/4] arm64: dts: qcom: Add AOSS QMP node

[Bjorn Andersson]

The AOSS QMP provides a number of power domains, used for QDSS and
PIL, add the node for this.

Tested-by: Sibi Sankar 
Reviewed-by: Sibi Sankar 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v8:
- None

 arch/arm64/boot/dts/qcom/sdm845.dtsi | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi 
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index c5a5c5b086b1..c80881309f79 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2448,6 +2448,16 @@
#reset-cells = <1>;
};
 
+   aoss_qmp: qmp@c30 {
+   compatible = "qcom,sdm845-aoss-qmp";
+   reg = <0 0x0c30 0 0x10>;
+   interrupts = ;
+   mboxes = <_shared 0>;
+
+   #clock-cells = <0>;
+   #power-domain-cells = <1>;
+   };
+
spmi_bus: spmi@c44 {
compatible = "qcom,spmi-pmic-arb";
reg = <0 0x0c44 0 0x1100>,
-- 
2.18.0

[PATCH v9 1/4] dt-bindings: soc: qcom: Add AOSS QMP binding

[Bjorn Andersson]

Add binding for the QMP based side-channel communication mechanism to
the AOSS, which is used to control resources not exposed through the
RPMh interface.

Reviewed-by: Rob Herring 
Reviewed-by: Vinod Koul 
Signed-off-by: Bjorn Andersson 
---

Changes since v8:
- None

 .../bindings/soc/qcom/qcom,aoss-qmp.txt   | 81 +++
 include/dt-bindings/power/qcom-aoss-qmp.h | 14 
 2 files changed, 95 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
 create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
new file mode 100644
index ..954ffee0a9c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
@@ -0,0 +1,81 @@
+Qualcomm Always-On Subsystem side channel binding
+
+This binding describes the hardware component responsible for side channel
+requests to the always-on subsystem (AOSS), used for certain power management
+requests that is not handled by the standard RPMh interface. Each client in the
+SoC has it's own block of message RAM and IRQ for communication with the AOSS.
+The protocol used to communicate in the message RAM is known as Qualcomm
+Messaging Protocol (QMP)
+
+The AOSS side channel exposes control over a set of resources, used to control
+a set of debug related clocks and to affect the low power state of resources
+related to the secondary subsystems. These resources are exposed as a set of
+power-domains.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be "qcom,sdm845-aoss-qmp"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: the base address and size of the message RAM for this
+   client's communication with the AOSS
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the AOSS message IRQ for this client
+
+- mboxes:
+   Usage: required
+   Value type: 
+   Definition: reference to the mailbox representing the outgoing doorbell
+   in APCS for this client, as described in mailbox/mailbox.txt
+
+- #clock-cells:
+   Usage: optional
+   Value type: 
+   Definition: must be 0
+   The single clock represents the QDSS clock.
+
+- #power-domain-cells:
+   Usage: optional
+   Value type: 
+   Definition: must be 1
+   The provided power-domains are:
+   CDSP state (0), LPASS state (1), modem state (2), SLPI
+   state (3), SPSS state (4) and Venus state (5).
+
+= SUBNODES
+The AOSS side channel also provides the controls for three cooling devices,
+these are expressed as subnodes of the QMP node. The name of the node is used
+to identify the resource and must therefor be "cx", "mx" or "ebi".
+
+- #cooling-cells:
+   Usage: optional
+   Value type: 
+   Definition: must be 2
+
+= EXAMPLE
+
+The following example represents the AOSS side-channel message RAM and the
+mechanism exposing the power-domains, as found in SDM845.
+
+  aoss_qmp: qmp@c30 {
+ compatible = "qcom,sdm845-aoss-qmp";
+ reg = <0x0c30 0x10>;
+ interrupts = ;
+ mboxes = <_shared 0>;
+
+ #power-domain-cells = <1>;
+
+ cx_cdev: cx {
+   #cooling-cells = <2>;
+ };
+
+ mx_cdev: mx {
+   #cooling-cells = <2>;
+ };
+  };
diff --git a/include/dt-bindings/power/qcom-aoss-qmp.h 
b/include/dt-bindings/power/qcom-aoss-qmp.h
new file mode 100644
index ..ec336d31dee4
--- /dev/null
+++ b/include/dt-bindings/power/qcom-aoss-qmp.h
@@ -0,0 +1,14 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2018, Linaro Ltd. */
+
+#ifndef __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+#define __DT_BINDINGS_POWER_QCOM_AOSS_QMP_H
+
+#define AOSS_QMP_LS_CDSP   0
+#define AOSS_QMP_LS_LPASS  1
+#define AOSS_QMP_LS_MODEM  2
+#define AOSS_QMP_LS_SLPI   3
+#define AOSS_QMP_LS_SPSS   4
+#define AOSS_QMP_LS_VENUS  5
+
+#endif
-- 
2.18.0

[PATCH v9 2/4] soc: qcom: Add AOSS QMP driver

[Bjorn Andersson]

The Always On Subsystem (AOSS) Qualcomm Messaging Protocol (QMP) driver
is used to communicate with the AOSS for certain side-channel requests,
that are not available through the RPMh interface.

The communication is a very simple synchronous mechanism of messages
being written in message RAM and a doorbell in the AOSS is rung. As the
AOSS has processed the message length is cleared and an interrupt is
fired by the AOSS as acknowledgment.

The driver exposes the QDSS clock as a clock and the low-power state
associated with the remoteprocs in the system as a set of power-domains.

Reviewed-by: Douglas Anderson 
Reviewed-by: Vinod Koul 
Tested-by: Sai Prakash Ranjan 
Signed-off-by: Bjorn Andersson 
---

Changes since v8:
- ret => time_left
- static const the clk_init_data

 drivers/soc/qcom/Kconfig |  12 +
 drivers/soc/qcom/Makefile|   1 +
 drivers/soc/qcom/qcom_aoss.c | 480 +++
 3 files changed, 493 insertions(+)
 create mode 100644 drivers/soc/qcom/qcom_aoss.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 880cf0290962..1ecd95a1c654 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -4,6 +4,18 @@
 #
 menu "Qualcomm SoC drivers"
 
+config QCOM_AOSS_QMP
+   tristate "Qualcomm AOSS Driver"
+   depends on ARCH_QCOM || COMPILE_TEST
+   depends on MAILBOX
+   depends on COMMON_CLK
+   select PM_GENERIC_DOMAINS
+   help
+ This driver provides the means of communicating with and controlling
+ the low-power state for resources related to the remoteproc
+ subsystems as well as controlling the debug clocks exposed by the 
Always On
+ Subsystem (AOSS) using Qualcomm Messaging Protocol (QMP).
+
 config QCOM_COMMAND_DB
bool "Qualcomm Command DB"
depends on ARCH_QCOM || COMPILE_TEST
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index ffe519b0cb66..eeb088beb15f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 CFLAGS_rpmh-rsc.o := -I$(src)
+obj-$(CONFIG_QCOM_AOSS_QMP) += qcom_aoss.o
 obj-$(CONFIG_QCOM_GENI_SE) +=  qcom-geni-se.o
 obj-$(CONFIG_QCOM_COMMAND_DB) += cmd-db.o
 obj-$(CONFIG_QCOM_GLINK_SSR) +=glink_ssr.o
diff --git a/drivers/soc/qcom/qcom_aoss.c b/drivers/soc/qcom/qcom_aoss.c
new file mode 100644
index ..5f885196f4d0
--- /dev/null
+++ b/drivers/soc/qcom/qcom_aoss.c
@@ -0,0 +1,480 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2019, Linaro Ltd
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define QMP_DESC_MAGIC 0x0
+#define QMP_DESC_VERSION   0x4
+#define QMP_DESC_FEATURES  0x8
+
+/* AOP-side offsets */
+#define QMP_DESC_UCORE_LINK_STATE  0xc
+#define QMP_DESC_UCORE_LINK_STATE_ACK  0x10
+#define QMP_DESC_UCORE_CH_STATE0x14
+#define QMP_DESC_UCORE_CH_STATE_ACK0x18
+#define QMP_DESC_UCORE_MBOX_SIZE   0x1c
+#define QMP_DESC_UCORE_MBOX_OFFSET 0x20
+
+/* Linux-side offsets */
+#define QMP_DESC_MCORE_LINK_STATE  0x24
+#define QMP_DESC_MCORE_LINK_STATE_ACK  0x28
+#define QMP_DESC_MCORE_CH_STATE0x2c
+#define QMP_DESC_MCORE_CH_STATE_ACK0x30
+#define QMP_DESC_MCORE_MBOX_SIZE   0x34
+#define QMP_DESC_MCORE_MBOX_OFFSET 0x38
+
+#define QMP_STATE_UP   GENMASK(15, 0)
+#define QMP_STATE_DOWN GENMASK(31, 16)
+
+#define QMP_MAGIC  0x4d41494c /* mail */
+#define QMP_VERSION1
+
+/* 64 bytes is enough to store the requests and provides padding to 4 bytes */
+#define QMP_MSG_LEN64
+
+/**
+ * struct qmp - driver state for QMP implementation
+ * @msgram: iomem referencing the message RAM used for communication
+ * @dev: reference to QMP device
+ * @mbox_client: mailbox client used to ring the doorbell on transmit
+ * @mbox_chan: mailbox channel used to ring the doorbell on transmit
+ * @offset: offset within @msgram where messages should be written
+ * @size: maximum size of the messages to be transmitted
+ * @event: wait_queue for synchronization with the IRQ
+ * @tx_lock: provides synchronization between multiple callers of qmp_send()
+ * @qdss_clk: QDSS clock hw struct
+ * @pd_data: genpd data
+ */
+struct qmp {
+   void __iomem *msgram;
+   struct device *dev;
+
+   struct mbox_client mbox_client;
+   struct mbox_chan *mbox_chan;
+
+   size_t offset;
+   size_t size;
+
+   wait_queue_head_t event;
+
+   struct mutex tx_lock;
+
+   struct clk_hw qdss_clk;
+   struct genpd_onecell_data pd_data;
+};
+
+struct qmp_pd {
+   struct qmp *qmp;
+   struct generic_pm_domain pd;
+};
+
+#define to_qmp_pd_resource(res) container_of(res, struct qmp_pd, pd)
+
+static void qmp_kick(struct qmp *qmp)
+{
+   mbox_send_message(qmp->mbox_chan, NULL);
+   

[PATCH v9 0/4] Qualcomm AOSS QMP driver

[Bjorn Andersson]

Add binding for the QMP based side-channel communication mechanism to
the AOSS, which is used to control resources not exposed through the
RPMh interface.

Bjorn Andersson (3):
  dt-bindings: soc: qcom: Add AOSS QMP binding
  soc: qcom: Add AOSS QMP driver
  arm64: dts: qcom: Add AOSS QMP node

Sibi Sankar (1):
  arm64: dts: qcom: sdm845: Add Q6V5 MSS node

 .../bindings/soc/qcom/qcom,aoss-qmp.txt   |  81 +++
 arch/arm64/boot/dts/qcom/sdm845.dtsi  |  68 +++
 drivers/soc/qcom/Kconfig  |  12 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/qcom_aoss.c  | 480 ++
 include/dt-bindings/power/qcom-aoss-qmp.h |  14 +
 6 files changed, 656 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt
 create mode 100644 drivers/soc/qcom/qcom_aoss.c
 create mode 100644 include/dt-bindings/power/qcom-aoss-qmp.h

-- 
2.18.0

Re: [PATCH v2 3/5] locking/qspinlock: Introduce CNA into the slow path of qspinlock

[Alex Kogan]

Hi, Wei.

> On Jun 11, 2019, at 12:22 AM, liwei (GF)  wrote:
> 
> Hi Alex,
> 
> On 2019/3/29 23:20, Alex Kogan wrote:
>> In CNA, spinning threads are organized in two queues, a main queue for
>> threads running on the same node as the current lock holder, and a
>> secondary queue for threads running on other nodes. At the unlock time,
>> the lock holder scans the main queue looking for a thread running on
>> the same node. If found (call it thread T), all threads in the main queue
>> between the current lock holder and T are moved to the end of the
>> secondary queue, and the lock is passed to T. If such T is not found, the
>> lock is passed to the first node in the secondary queue. Finally, if the
>> secondary queue is empty, the lock is passed to the next thread in the
>> main queue. For more details, see 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__arxiv.org_abs_1810.05600=DwICbg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=Hvhk3F4omdCk-GE1PTOm3Kn0A7ApWOZ2aZLTuVxFK4k=U7mfTbYj1r2Te2BBUUNbVrRPuTa_ujlpR4GZfUsrGTM=Dw4O1EniF-nde4fp6RA9ISlSMOjWuqeR9OS1G0iauj0=.
>> 
>> Note that this variant of CNA may introduce starvation by continuously
>> passing the lock to threads running on the same node. This issue
>> will be addressed later in the series.
>> 
>> Enabling CNA is controlled via a new configuration option
>> (NUMA_AWARE_SPINLOCKS), which is enabled by default if NUMA is enabled.
>> 
>> Signed-off-by: Alex Kogan 
>> Reviewed-by: Steve Sistare 
>> ---
>> arch/x86/Kconfig  |  14 +++
>> include/asm-generic/qspinlock_types.h |  13 +++
>> kernel/locking/mcs_spinlock.h |  10 ++
>> kernel/locking/qspinlock.c|  29 +-
>> kernel/locking/qspinlock_cna.h| 173 
>> ++
>> 5 files changed, 236 insertions(+), 3 deletions(-)
>> create mode 100644 kernel/locking/qspinlock_cna.h
>> 
> (SNIP)
>> +
>> +static __always_inline int get_node_index(struct mcs_spinlock *node)
>> +{
>> +return decode_count(node->node_and_count++);
> When nesting level is > 4, it won't return a index >= 4 here and the numa 
> node number
> is changed by mistake. It will go into a wrong way instead of the following 
> branch.
> 
> 
>   /*
>* 4 nodes are allocated based on the assumption that there will
>* not be nested NMIs taking spinlocks. That may not be true in
>* some architectures even though the chance of needing more than
>* 4 nodes will still be extremely unlikely. When that happens,
>* we fall back to spinning on the lock directly without using
>* any MCS node. This is not the most elegant solution, but is
>* simple enough.
>*/
>   if (unlikely(idx >= MAX_NODES)) {
>   while (!queued_spin_trylock(lock))
>   cpu_relax();
>   goto release;
>   }
Good point.
This patch does not handle count overflows gracefully.
It can be easily fixed by allocating more bits for the count — we don’t really 
need 30 bits for #NUMA nodes.

However, I am working on a new revision of the patch, in which the cna node 
encapsulates the mcs node (following Peter’s suggestion and similarly to 
pv_node).
With that approach, this issue is gone.

Best regards,
— Alex

[PATCH v6 3/3] arm64: kexec_file: add rng-seed support

[Hsin-Yi Wang]

Adding "rng-seed" to dtb. It's fine to add this property if original
fdt doesn't contain it. Since original seed will be wiped after
read, so use a default size 128 bytes here.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Stephen Boyd 
---
change log v5->v6:
* no change
---
 arch/arm64/kernel/machine_kexec_file.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/machine_kexec_file.c 
b/arch/arm64/kernel/machine_kexec_file.c
index 58871333737a..d40fde72a023 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -27,6 +27,8 @@
 #define FDT_PROP_INITRD_END"linux,initrd-end"
 #define FDT_PROP_BOOTARGS  "bootargs"
 #define FDT_PROP_KASLR_SEED"kaslr-seed"
+#define FDT_PROP_RNG_SEED  "rng-seed"
+#define RNG_SEED_SIZE  128
 
 const struct kexec_file_ops * const kexec_file_loaders[] = {
_image_ops,
@@ -102,6 +104,23 @@ static int setup_dtb(struct kimage *image,
FDT_PROP_KASLR_SEED);
}
 
+   /* add rng-seed */
+   if (rng_is_initialized()) {
+   void *rng_seed = kmalloc(RNG_SEED_SIZE, GFP_ATOMIC);
+   get_random_bytes(rng_seed, RNG_SEED_SIZE);
+
+   ret = fdt_setprop(dtb, off, FDT_PROP_RNG_SEED, rng_seed,
+   RNG_SEED_SIZE);
+   kfree(rng_seed);
+
+   if (ret)
+   goto out;
+
+   } else {
+   pr_notice("RNG is not initialised: omitting \"%s\" property\n",
+   FDT_PROP_RNG_SEED);
+   }
+
 out:
if (ret)
return (ret == -FDT_ERR_NOSPACE) ? -ENOMEM : -EINVAL;
@@ -110,7 +129,8 @@ static int setup_dtb(struct kimage *image,
 }
 
 /*
- * More space needed so that we can add initrd, bootargs and kaslr-seed.
+ * More space needed so that we can add initrd, bootargs, kaslr-seed, and
+ * rng-seed.
  */
 #define DTB_EXTRA_SPACE 0x1000
 
-- 
2.20.1

[PATCH v6 2/3] fdt: add support for rng-seed

[Hsin-Yi Wang]

Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. Bootloader should provide this entropy and the value is
read from /chosen/rng-seed in DT.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Stephen Boyd 
---
change log v5->v6:
* remove Documentation change
---
 drivers/of/fdt.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 3d36b5afd9bd..369130dbd42c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include   /* for COMMAND_LINE_SIZE */
 #include 
@@ -1052,6 +1053,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 {
int l;
const char *p;
+   const void *rng_seed;
 
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
 
@@ -1086,6 +1088,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, 
const char *uname,
 
pr_debug("Command line is: %s\n", (char*)data);
 
+   rng_seed = of_get_flat_dt_prop(node, "rng-seed", );
+   if (rng_seed && l > 0) {
+   add_device_randomness(rng_seed, l);
+
+   /* try to clear seed so it won't be found. */
+   fdt_nop_property(initial_boot_params, node, "rng-seed");
+   }
+
/* break now */
return 1;
 }
-- 
2.20.1

[PATCH v6 1/3] arm64: map FDT as RW for early_init_dt_scan()

[Hsin-Yi Wang]

Currently in arm64, FDT is mapped to RO before it's passed to
early_init_dt_scan(). However, there might be some codes
(eg. commit "fdt: add support for rng-seed") that need to modify FDT
during init. Map FDT to RO after early fixups are done.

Signed-off-by: Hsin-Yi Wang 
Reviewed-by: Stephen Boyd 
---
change log v5->v6:
* no change.
---
 arch/arm64/include/asm/mmu.h |  2 +-
 arch/arm64/kernel/kaslr.c|  5 +
 arch/arm64/kernel/setup.c|  9 -
 arch/arm64/mm/mmu.c  | 15 +--
 4 files changed, 11 insertions(+), 20 deletions(-)

diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index 67ef25d037ea..27f6f17aae36 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -137,7 +137,7 @@ extern void init_mem_pgprot(void);
 extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
   unsigned long virt, phys_addr_t size,
   pgprot_t prot, bool page_mappings_only);
-extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
+extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
 extern void mark_linear_text_alias_ro(void);
 
 #define INIT_MM_CONTEXT(name)  \
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 06941c1fe418..92bb53460401 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -65,9 +65,6 @@ static __init const u8 *kaslr_get_cmdline(void *fdt)
return default_cmdline;
 }
 
-extern void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size,
-  pgprot_t prot);
-
 /*
  * This routine will be executed with the kernel mapped at its default virtual
  * address, and if it returns successfully, the kernel will be remapped, and
@@ -96,7 +93,7 @@ u64 __init kaslr_early_init(u64 dt_phys)
 * attempt at mapping the FDT in setup_machine()
 */
early_fixmap_init();
-   fdt = __fixmap_remap_fdt(dt_phys, , PAGE_KERNEL);
+   fdt = fixmap_remap_fdt(dt_phys, , PAGE_KERNEL);
if (!fdt)
return 0;
 
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 413d566405d1..6a7050319b5b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -181,9 +181,13 @@ static void __init smp_build_mpidr_hash(void)
 
 static void __init setup_machine_fdt(phys_addr_t dt_phys)
 {
-   void *dt_virt = fixmap_remap_fdt(dt_phys);
+   int size;
+   void *dt_virt = fixmap_remap_fdt(dt_phys, , PAGE_KERNEL);
const char *name;
 
+   if (dt_virt)
+   memblock_reserve(dt_phys, size);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address 
%pa (virtual address 0x%p)\n"
@@ -195,6 +199,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
cpu_relax();
}
 
+   /* Early fixups are done, map the FDT as read-only now */
+   fixmap_remap_fdt(dt_phys, , PAGE_KERNEL_RO);
+
name = of_flat_dt_get_machine_name();
if (!name)
return;
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 93ed0df4df79..5d01365a4333 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -887,7 +887,7 @@ void __set_fixmap(enum fixed_addresses idx,
}
 }
 
-void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
+void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
 {
const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
int offset;
@@ -940,19 +940,6 @@ void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int 
*size, pgprot_t prot)
return dt_virt;
 }
 
-void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
-{
-   void *dt_virt;
-   int size;
-
-   dt_virt = __fixmap_remap_fdt(dt_phys, , PAGE_KERNEL_RO);
-   if (!dt_virt)
-   return NULL;
-
-   memblock_reserve(dt_phys, size);
-   return dt_virt;
-}
-
 int __init arch_ioremap_pud_supported(void)
 {
/*
-- 
2.20.1

[PATCH v6 0/3] add support for rng-seed

[Hsin-Yi Wang]

Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness.

Hsin-Yi Wang (3):
  arm64: map FDT as RW for early_init_dt_scan()
  fdt: add support for rng-seed
  arm64: kexec_file: add rng-seed support

 arch/arm64/include/asm/mmu.h   |  2 +-
 arch/arm64/kernel/kaslr.c  |  5 +
 arch/arm64/kernel/machine_kexec_file.c | 22 +-
 arch/arm64/kernel/setup.c  |  9 -
 arch/arm64/mm/mmu.c| 15 +--
 drivers/of/fdt.c   | 10 ++
 6 files changed, 42 insertions(+), 21 deletions(-)

-- 
2.20.1

RE: [PATCHv6 3/3] vfio/mdev: Synchronize device create/remove with parent removal

[Parav Pandit]

> -Original Message-
> From: Alex Williamson 
> Sent: Tuesday, June 11, 2019 11:25 PM
> To: Parav Pandit 
> Cc: Cornelia Huck ; k...@vger.kernel.org; linux-
> ker...@vger.kernel.org; kwankh...@nvidia.com; c...@nvidia.com
> Subject: Re: [PATCHv6 3/3] vfio/mdev: Synchronize device create/remove
> with parent removal
> 
> On Tue, 11 Jun 2019 03:22:37 +
> Parav Pandit  wrote:
> 
> > Hi Alex,
> >
> [snip]
> 
> > Now that we have all 3 patches reviewed and comments addressed, if
> > there are no more comments, can you please take it forward?
> 
> Yep, I put it in a branch rolled into linux-next for upstream testing last 
> week
> and just sent a pull request to Linus today.  Thanks,
> 
Oh ok. Great. Thanks Alex.

Re: [PATCH] dmaengine: dw-edma: Fix build error without CONFIG_PCI_MSI

[Yuehaibing]

Pls ignore this, will fix patch title and resend

On 2019/6/12 12:18, YueHaibing wrote:
> If CONFIG_PCI_MSI is not set, building with CONFIG_DW_EDMA
> fails:
> 
> drivers/dma/dw-edma/dw-edma-core.c: In function dw_edma_irq_request:
> drivers/dma/dw-edma/dw-edma-core.c:784:21: error: implicit declaration of 
> function pci_irq_vector; did you mean rcu_irq_enter? 
> [-Werror=implicit-function-declaration]
>err = request_irq(pci_irq_vector(to_pci_dev(dev), 0),
>  ^~
> 
> Reported-by: Hulk Robot 
> Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
> Signed-off-by: YueHaibing 
> ---
>  drivers/dma/dw-edma/Kconfig | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/dma/dw-edma/Kconfig b/drivers/dma/dw-edma/Kconfig
> index c0838ce..7ff17b2 100644
> --- a/drivers/dma/dw-edma/Kconfig
> +++ b/drivers/dma/dw-edma/Kconfig
> @@ -2,6 +2,7 @@
>  
>  config DW_EDMA
>   tristate "Synopsys DesignWare eDMA controller driver"
> + depends on PCI && PCI_MSI
>   select DMA_ENGINE
>   select DMA_VIRTUAL_CHANNELS
>   help
> 

[PATCH -next] dmaengine: dw-edma: Fix build error without CONFIG_PCI_MSI

[YueHaibing]

If CONFIG_PCI_MSI is not set, building with CONFIG_DW_EDMA
fails:

drivers/dma/dw-edma/dw-edma-core.c: In function dw_edma_irq_request:
drivers/dma/dw-edma/dw-edma-core.c:784:21: error: implicit declaration of 
function pci_irq_vector; did you mean rcu_irq_enter? 
[-Werror=implicit-function-declaration]
   err = request_irq(pci_irq_vector(to_pci_dev(dev), 0),
 ^~

Reported-by: Hulk Robot 
Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
Signed-off-by: YueHaibing 
---
 drivers/dma/dw-edma/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/dw-edma/Kconfig b/drivers/dma/dw-edma/Kconfig
index c0838ce..7ff17b2 100644
--- a/drivers/dma/dw-edma/Kconfig
+++ b/drivers/dma/dw-edma/Kconfig
@@ -2,6 +2,7 @@
 
 config DW_EDMA
tristate "Synopsys DesignWare eDMA controller driver"
+   depends on PCI && PCI_MSI
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
-- 
2.7.4

[PATCH] dmaengine: dw-edma: Fix build error without CONFIG_PCI_MSI

[YueHaibing]

If CONFIG_PCI_MSI is not set, building with CONFIG_DW_EDMA
fails:

drivers/dma/dw-edma/dw-edma-core.c: In function dw_edma_irq_request:
drivers/dma/dw-edma/dw-edma-core.c:784:21: error: implicit declaration of 
function pci_irq_vector; did you mean rcu_irq_enter? 
[-Werror=implicit-function-declaration]
   err = request_irq(pci_irq_vector(to_pci_dev(dev), 0),
 ^~

Reported-by: Hulk Robot 
Fixes: e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver")
Signed-off-by: YueHaibing 
---
 drivers/dma/dw-edma/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/dma/dw-edma/Kconfig b/drivers/dma/dw-edma/Kconfig
index c0838ce..7ff17b2 100644
--- a/drivers/dma/dw-edma/Kconfig
+++ b/drivers/dma/dw-edma/Kconfig
@@ -2,6 +2,7 @@
 
 config DW_EDMA
tristate "Synopsys DesignWare eDMA controller driver"
+   depends on PCI && PCI_MSI
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
help
-- 
2.7.4

RE: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2

[Y.b. Lu]

Hi Andrew,

> -Original Message-
> From: Andrew Lunn 
> Sent: 2019年6月10日 21:06
> To: Y.b. Lu 
> Cc: net...@vger.kernel.org; David S . Miller ;
> Richard Cochran ; Rob Herring
> ; Shawn Guo ;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH 1/6] ptp: add QorIQ PTP support for DPAA2
> 
> On Mon, Jun 10, 2019 at 11:21:03AM +0800, Yangbo Lu wrote:
> > This patch is to add QorIQ PTP support for DPAA2.
> > Although dpaa2-ptp.c driver is a fsl_mc_driver which is using MC APIs
> > for register accessing, it's same IP block with eTSEC/DPAA/ENETC 1588
> > timer. We will convert to reuse ptp_qoriq driver by using register
> > ioremap and dropping related MC APIs.
> >
> > Signed-off-by: Yangbo Lu 
> > ---
> >  drivers/ptp/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig index
> > 9b8fee5..b1b454f 100644
> > --- a/drivers/ptp/Kconfig
> > +++ b/drivers/ptp/Kconfig
> > @@ -44,7 +44,7 @@ config PTP_1588_CLOCK_DTE
> >
> >  config PTP_1588_CLOCK_QORIQ
> > tristate "Freescale QorIQ 1588 timer as PTP clock"
> > -   depends on GIANFAR || FSL_DPAA_ETH || FSL_ENETC || FSL_ENETC_VF
> > +   depends on GIANFAR || FSL_DPAA_ETH || FSL_DPAA2_ETH ||
> FSL_ENETC ||
> > +FSL_ENETC_VF
> > depends on PTP_1588_CLOCK
> 
> Hi Yangbo
> 
> Could COMPILE_TEST also be added?

[Y.b. Lu] COMPILE_TEST is usually for other ARCHs build coverage.
Do you want me to append it after these Ethernet driver dependencies?

Thanks.

> 
> Thanks
>   Andrew

Re: [RFC] Disable lockref on arm64

[Jayachandran Chandrasekharan Nair]

On Wed, May 22, 2019 at 05:04:17PM +0100, Will Deacon wrote:
> On Sat, May 18, 2019 at 12:00:34PM +0200, Ard Biesheuvel wrote:
> > On Sat, 18 May 2019 at 06:25, Jayachandran Chandrasekharan Nair
> >  wrote:
> > >
> > > On Mon, May 06, 2019 at 07:10:40PM +0100, Will Deacon wrote:
> > > > On Mon, May 06, 2019 at 06:13:12AM +, Jayachandran Chandrasekharan 
> > > > Nair wrote:
> > > > > Perhaps someone from ARM can chime in here how the cas/yield combo
> > > > > is expected to work when there is contention. ThunderX2 does not
> > > > > do much with the yield, but I don't expect any ARM implementation
> > > > > to treat YIELD as a hint not to yield, but to get/keep exclusive
> > > > > access to the last failed CAS location.
> > > >
> > > > Just picking up on this as "someone from ARM".
> > > >
> > > > The yield instruction in our implementation of cpu_relax() is *only* 
> > > > there
> > > > as a scheduling hint to QEMU so that it can treat it as an internal
> > > > scheduling hint and run some other thread; see 1baa82f48030 ("arm64:
> > > > Implement cpu_relax as yield"). We can't use WFE or WFI blindly here, 
> > > > as it
> > > > could be a long time before we see a wake-up event such as an 
> > > > interrupt. Our
> > > > implementation of smp_cond_load_acquire() is much better for that kind 
> > > > of
> > > > thing, but doesn't help at all for a contended CAS loop where the 
> > > > variable
> > > > is actually changing constantly.
> > >
> > > Looking thru the perf output of this case (open/close of a file from
> > > multiple CPUs), I see that refcount is a significant factor in most
> > > kernel configurations - and that too uses cmpxchg (without yield).
> > > x86 has an optimized inline version of refcount that helps
> > > significantly. Do you think this is worth looking at for arm64?
> > >
> > 
> > I looked into this a while ago [0], but at the time, we decided to
> > stick with the generic implementation until we encountered a use case
> > that benefits from it. Worth a try, I suppose ...
> > 
> > [0] 
> > https://lore.kernel.org/linux-arm-kernel/20170903101622.12093-1-ard.biesheu...@linaro.org/
> 
> If JC can show that we benefit from this, it would be interesting to see if
> we can implement the refcount-full saturating arithmetic using the
> LDMIN/LDMAX instructions instead of the current cmpxchg() loops.

Now that the lockref change is mainline, I think we need to take another
look at this patch.

Using a fixed up version of Ard's patch above along with Jan's lockref
change upstream, I get significant improvement in scaling for my file
open/read/close testcase[1]. Like I wrote earlier, if I take a
standard Ubuntu arm64 kernel configuration, most of the time for my
test[1] is spent in refcount operations.

With Ard's changes applied[2], I see that the lockref CAS code becomes
the top function and then the retry limit will kick in as expected. In
my testcase, I see that the queued spinlock case is about 2.5 times
faster than the unbound CAS loop when 224 CPUs are enabled (SMT 4,
28core, 2socket).

JC

[1] https://github.com/jchandra-cavm/refcount-test
[2] https://github.com/jchandra-cavm/linux/commits/refcount-fixes

Re: [RFC PATCH] x86/cpufeatures: Enumerate new AVX512 bfloat16 instructions

[Borislav Petkov]

On Tue, Jun 11, 2019 at 08:32:59PM -0700, Fenghua Yu wrote:
> Currently KVM doesn't simulate scattered features (the ones in CPUID_LNX_*
> in cpuid_leafs) as reverse_cpuid[] doesn't contain CPUID_LNX_*.

43500e6f294d ("x86/cpufeatures: Remove get_scattered_cpuid_leaf()")

> After the X86_FEATURES_CQM_* features are changed to scattered features,
> they will not be simulated by KVM any more as CPUID_F_0_EDX and CPUID_F_1_EDX
> are removed.

Does KVM even support resctrl? I doubt only exporting a couple of CPUID
bits into the guest is enough...

> Should patch #1 simulate X86_FEATURE_CQM_* in KVM? Or let KVM guys handle
> the scattered features?

Right, the scattered thing was removed as KVM didn't need it,
apparently, see above.

-- 
Regards/Gruss,
Boris.

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

Re: [PATCH V5 - Rebased] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()

[Anshuman Khandual]

On 06/12/2019 03:49 AM, Andrew Morton wrote:
> On Tue, 11 Jun 2019 16:56:13 +0530 Anshuman Khandual 
>  wrote:
> 
>> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
>> entries between memory block and node. It first checks pfn validity with
>> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config
>> (arm64 has this enabled) pfn_valid_within() calls pfn_valid().
>>
>> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID)
>> which scans all mapped memblock regions with memblock_is_map_memory(). This
>> creates a problem in memory hot remove path which has already removed given
>> memory range from memory block with memblock_[remove|free] before arriving
>> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1
>> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block
>> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because
>> of existing sysfs entries.
>>
>> [   62.007176] NUMA: Unknown node for memory at 0x68000, assuming node 0
>> [   62.052517] [ cut here ]
>> [   62.053211] kernel BUG at mm/memory_hotplug.c:1143!
>> [   62.053868] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>> [   62.054589] Modules linked in:
>> [   62.054999] CPU: 19 PID: 3275 Comm: bash Not tainted 
>> 5.1.0-rc2-4-g28cea40b2683 #41
>> [   62.056274] Hardware name: linux,dummy-virt (DT)
>> [   62.057166] pstate: 4045 (nZcv daif +PAN -UAO)
>> [   62.058083] pc : add_memory_resource+0x1cc/0x1d8
>> [   62.058961] lr : add_memory_resource+0x10c/0x1d8
>> [   62.059842] sp : 168b3ce0
>> [   62.060477] x29: 168b3ce0 x28: 8005db546c00
>> [   62.061501] x27:  x26: 
>> [   62.062509] x25: 111ef000 x24: 111ef5d0
>> [   62.063520] x23:  x22: 0006bfff
>> [   62.064540] x21: ffef x20: 006c
>> [   62.065558] x19: 0068 x18: 0024
>> [   62.066566] x17:  x16: 
>> [   62.067579] x15:  x14: 8005e412e890
>> [   62.068588] x13: 8005d6b105d8 x12: 
>> [   62.069610] x11: 8005d6b10490 x10: 0040
>> [   62.070615] x9 : 8005e412e898 x8 : 8005e412e890
>> [   62.071631] x7 : 8005d6b105d8 x6 : 8005db546c00
>> [   62.072640] x5 : 0001 x4 : 0002
>> [   62.073654] x3 : 8005d7049480 x2 : 0002
>> [   62.074666] x1 : 0003 x0 : ffef
>> [   62.075685] Process bash (pid: 3275, stack limit = 0xd754280f)
>> [   62.076930] Call trace:
>> [   62.077411]  add_memory_resource+0x1cc/0x1d8
>> [   62.078227]  __add_memory+0x70/0xa8
>> [   62.078901]  probe_store+0xa4/0xc8
>> [   62.079561]  dev_attr_store+0x18/0x28
>> [   62.080270]  sysfs_kf_write+0x40/0x58
>> [   62.080992]  kernfs_fop_write+0xcc/0x1d8
>> [   62.081744]  __vfs_write+0x18/0x40
>> [   62.082400]  vfs_write+0xa4/0x1b0
>> [   62.083037]  ksys_write+0x5c/0xc0
>> [   62.083681]  __arm64_sys_write+0x18/0x20
>> [   62.084432]  el0_svc_handler+0x88/0x100
>> [   62.085177]  el0_svc+0x8/0xc
> 
> This seems like a serious problem.  Once which should be fixed in 5.2
> and perhaps the various -stable kernels as well.

But the problem does not exist in the current kernel as yet till the reworked
versions of the other two patches in this series get merged. This patch was
after arm64 hot-remove enablement in V1 (https://lkml.org/lkml/2019/4/3/28)
but after some discussions it was decided to be moved before hot-remove from
V2 (https://lkml.org/lkml/2019/4/14/5) onwards as a prerequisite patch instead.

> 
>> Re-ordering memblock_[free|remove]() with arch_remove_memory() solves the
>> problem on arm64 as pfn_valid() behaves correctly and returns positive
>> as memblock for the address range still exists. arch_remove_memory()
>> removes applicable memory sections from zone with __remove_pages() and
>> tears down kernel linear mapping. Removing memblock regions afterwards
>> is safe because there is no other memblock (bootmem) allocator user that
>> late. So nobody is going to allocate from the removed range just to blow
>> up later. Also nobody should be using the bootmem allocated range else
>> we wouldn't allow to remove it. So reordering is indeed safe.
>>
>> ...
>>
>>
>> - Rebased on linux-next (next-20190611)
> 
> Yet the patch you've prepared is designed for 5.3.  Was that
> deliberate, or should we be targeting earlier kernels?

It was deliberate for 5.3 as a preparation for upcoming reworked arm64 
hot-remove.

Re: [RFC PATCH] x86/cpufeatures: Enumerate new AVX512 bfloat16 instructions

[Borislav Petkov]

On Wed, Jun 12, 2019 at 03:29:57AM +, Yu, Fenghua wrote:
> My bad. I studied a bit more and found the patch #1 is not needed.

Why, I think you were spot-on:

"And the two variables are ONLY used in resctrl monitoring
configuration. There is no need to store them in cpuinfo_x86 on each
CPU."

That was a real overkill to put them in cpuinfo_x86. The information
needed should simply be read out in rdt_get_mon_l3_config() and that's
it - no need to global values to store them.

Now removing them should be in a separate patch so that review is easy.

Or am I missing an aspect?

-- 
Regards/Gruss,
Boris.

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

RE: [PATCH 2/2] soc: imx8: Use existing of_root directly

[Aisheng Dong]

> From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> Sent: Wednesday, June 12, 2019 11:36 AM
> 
> There is common of_root for reference, no need to find it from DT again, use
> of_root directly to make driver simple.
> 
> Signed-off-by: Anson Huang 

Reviewed-by: Dong Aisheng 

Regards
Dong Aisheng

RE: [PATCH 1/2] soc: imx8: Fix potential kernel dump in error path

[Aisheng Dong]

> From: anson.hu...@nxp.com [mailto:anson.hu...@nxp.com]
> Sent: Wednesday, June 12, 2019 11:36 AM
> > 
> When SoC's revision value is 0, SoC driver will print out "unknown" in sysfs's
> revision node, this "unknown" is a static string which can NOT be freed, this
> will caused below kernel dump in later error path which calls kfree:
> 
> kernel BUG at mm/slub.c:3942!
> Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in:
> CPU: 2 PID: 1 Comm: swapper/0 Not tainted
> 5.2.0-rc4-next-20190611-00023-g705146c-dirty #2197 Hardware name: NXP
> i.MX8MQ EVK (DT)
> pstate: 6005 (nZCv daif -PAN -UAO)
> pc : kfree+0x170/0x1b0
> lr : imx8_soc_init+0xc0/0xe4
> sp : 1003bd10
> x29: 1003bd10 x28: 1121e0a0
> x27: 11482000 x26: 1117068c
> x25: 1121e100 x24: 11482000
> x23: 10fe2b58 x22: 111b9ab0
> x21: 8000bd9dfba0 x20: 111b9b70
> x19: 7e43f880 x18: 1000
> x17: 10d05fa0 x16: 122e
> x15: 0140 x14: 3036
> x13: 8000b94b5bb0 x12: 0038
> x11:  x10: 
> x9 : 0003 x8 : 8000b9488147
> x7 : 1003bc00 x6 : 
> x5 : 0003 x4 : 0003
> x3 : 0003 x2 : b8793acd604edf00
> x1 : 7e43f880 x0 : 7e43f888 Call trace:
>  kfree+0x170/0x1b0
>  imx8_soc_init+0xc0/0xe4
>  do_one_initcall+0x58/0x1b8
>  kernel_init_freeable+0x1cc/0x288
>  kernel_init+0x10/0x100
>  ret_from_fork+0x10/0x18
> 
> This patch fixes this potential kernel dump when a chip's revision is 
> "unknown",
> it is done by always printing out the revision value.
> 
> Fixes: a7e26f356ca1 ("soc: imx: Add generic i.MX8 SoC driver")
> Signed-off-by: Anson Huang 
> ---
>  drivers/soc/imx/soc-imx8.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c index
> 02309a2..86b925a 100644
> --- a/drivers/soc/imx/soc-imx8.c
> +++ b/drivers/soc/imx/soc-imx8.c
> @@ -96,11 +96,6 @@ static const struct of_device_id imx8_soc_match[] = {
>   { }
>  };
> 
> -#define imx8_revision(soc_rev) \
> - soc_rev ? \
> - kasprintf(GFP_KERNEL, "%d.%d", (soc_rev >> 4) & 0xf,  soc_rev & 0xf) : \
> - "unknown"
> -
>  static int __init imx8_soc_init(void)
>  {
>   struct soc_device_attribute *soc_dev_attr; @@ -135,7 +130,10 @@
> static int __init imx8_soc_init(void)
>   soc_rev = data->soc_revision();
>   }
> 
> - soc_dev_attr->revision = imx8_revision(soc_rev);
> + soc_dev_attr->revision = kasprintf(GFP_KERNEL,
> +"%d.%d",
> +(soc_rev >> 4) & 0xf,
> +soc_rev & 0xf);

The revision "0.0" is confusing.
I might prefer to check "unknown" before free.

Regards
Dong Aisheng

>   if (!soc_dev_attr->revision) {
>   ret = -ENOMEM;
>   goto free_soc;
> --
> 2.7.4

Re: [LKP] [tcp] 8b27dae5a2: netperf.Throughput_Mbps -25.7% regression

[Feng Tang]

On Tue, Jun 04, 2019 at 06:07:35PM +0800, Feng Tang wrote:
> On Thu, May 30, 2019 at 11:23:14PM +0800, Feng Tang wrote:
> > Hi Eric,
> > 
> > On Thu, May 30, 2019 at 05:21:40AM -0700, Eric Dumazet wrote:
> > > On Thu, May 30, 2019 at 3:31 AM Feng Tang  wrote:
> > > >
> > > > On Wed, Apr 03, 2019 at 02:34:36PM +0800, kernel test robot wrote:
> > > > > Greeting,
> > > > >
> > > > > FYI, we noticed a -25.7% regression of netperf.Throughput_Mbps due to 
> > > > > commit:
> > > > >
> > > > >
> > > > > commit: 8b27dae5a2e89a61c46c6dbc76c040c0e6d0ed4c ("tcp: add one skb 
> > > > > cache for rx")
> > > > > https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git 
> > > > > master
> > > >
> > > > Hi Eric,
> > > >
> > > > Could you help to check this? thanks,
> > > >
> > > 
> > > Hmmm... patch is old and had some bugs that have been fixed.
> > > 
> > > What numbers do you have with more recent kernels ?
> > 
> > 
> > I just run the test  with 5.2-rc2, and the regression is still there.
> 
> Hi Eric,
> 
> Any hint on this?
> 
> >From the perf data, the spinlock contention has an obvious increase:
> 
> 9.28+7.6   16.91
> perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock.free_one_page.__free_pages_ok.___pskb_trim
> 18.55   +8.6   27.14
> perf-profile.calltrace.cycles-pp.native_queued_spin_lock_slowpath._raw_spin_lock_irqsave.get_page_from_freelist.__alloc_pages_nodemask.skb_page_frag_refill

Hi Eric,

Any thoughts?

Actually I did some further check. The increased lock contention
comes from the mm zone lock for page alloc/free. I did an 
experiment by changing the SKB_FRAG_PAGE_ORDER from 32K to 64K,
the lock contention is dramatically reduced, and the throughput
got some recovery (10% ~ 15% gain) depending on HW platform, but
can't fully recover the -25.7% loss. Hope this info helps.

Thanks,
Feng

> 
> And for commit 8b27dae5a2 ("tcp: add one skb cache for rx"), IIUC, it
> is not a real cache like the "tx skb cache" patch, and kind of a
> delayed freeing.
> 
> Thanks,
> Feng
> 
>  

[PATCH net v2] tcp: avoid creating multiple req socks with the same tuples

[Mao Wenan]

There is one issue about bonding mode BOND_MODE_BROADCAST, and
two slaves with diffierent affinity, so packets will be handled
by different cpu. These are two pre-conditions in this case.

When two slaves receive the same syn packets at the same time,
two request sock(reqsk) will be created if below situation happens:
1. syn1 arrived tcp_conn_request, create reqsk1 and have not yet called
inet_csk_reqsk_queue_hash_add.
2. syn2 arrived tcp_v4_rcv, it goes to tcp_conn_request and create
reqsk2
because it can't find reqsk1 in the __inet_lookup_skb.

Then reqsk1 and reqsk2 are added to establish hash table, and two synack
with different
seq(seq1 and seq2) are sent to client, then tcp ack arrived and will be
processed in tcp_v4_rcv and tcp_check_req, if __inet_lookup_skb find the
reqsk2, and
tcp ack packet is ack_seq is seq1, it will be failed after checking:
TCP_SKB_CB(skb)->ack_seq != tcp_rsk(req)->snt_isn + 1)
and then tcp rst will be sent to client and close the connection.

To fix this, call __inet_lookup_established() before __sk_nulls_add_node_rcu()
in inet_ehash_insert(). If there is existed reqsk with same tuples in
established hash table, directly to remove current reqsk2, and does not send
synack to client.

Signed-off-by: Mao Wenan 
---
 v2: move __inet_lookup_established from tcp_conn_request() to 
inet_ehash_insert()
 as Eric suggested.
---
 include/net/inet_connection_sock.h |  2 +-
 net/ipv4/inet_connection_sock.c| 16 
 net/ipv4/inet_hashtables.c | 13 +
 net/ipv4/tcp_input.c   |  7 ---
 4 files changed, 30 insertions(+), 8 deletions(-)

diff --git a/include/net/inet_connection_sock.h 
b/include/net/inet_connection_sock.h
index c57d53e7e02c..2d3538e333cb 100644
--- a/include/net/inet_connection_sock.h
+++ b/include/net/inet_connection_sock.h
@@ -263,7 +263,7 @@ struct dst_entry *inet_csk_route_child_sock(const struct 
sock *sk,
 struct sock *inet_csk_reqsk_queue_add(struct sock *sk,
  struct request_sock *req,
  struct sock *child);
-void inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock *req,
+bool inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock *req,
   unsigned long timeout);
 struct sock *inet_csk_complete_hashdance(struct sock *sk, struct sock *child,
 struct request_sock *req,
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 13ec7c3a9c49..fd45ed2fd985 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -749,7 +749,7 @@ static void reqsk_timer_handler(struct timer_list *t)
inet_csk_reqsk_queue_drop_and_put(sk_listener, req);
 }
 
-static void reqsk_queue_hash_req(struct request_sock *req,
+static bool reqsk_queue_hash_req(struct request_sock *req,
 unsigned long timeout)
 {
req->num_retrans = 0;
@@ -759,19 +759,27 @@ static void reqsk_queue_hash_req(struct request_sock *req,
timer_setup(>rsk_timer, reqsk_timer_handler, TIMER_PINNED);
mod_timer(>rsk_timer, jiffies + timeout);
 
-   inet_ehash_insert(req_to_sk(req), NULL);
+   if (!inet_ehash_insert(req_to_sk(req), NULL)) {
+   if (timer_pending(>rsk_timer))
+   del_timer_sync(>rsk_timer);
+   return false;
+   }
/* before letting lookups find us, make sure all req fields
 * are committed to memory and refcnt initialized.
 */
smp_wmb();
refcount_set(>rsk_refcnt, 2 + 1);
+   return true;
 }
 
-void inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock *req,
+bool inet_csk_reqsk_queue_hash_add(struct sock *sk, struct request_sock *req,
   unsigned long timeout)
 {
-   reqsk_queue_hash_req(req, timeout);
+   if (!reqsk_queue_hash_req(req, timeout))
+   return false;
+
inet_csk_reqsk_queue_added(sk);
+   return true;
 }
 EXPORT_SYMBOL_GPL(inet_csk_reqsk_queue_hash_add);
 
diff --git a/net/ipv4/inet_hashtables.c b/net/ipv4/inet_hashtables.c
index c4503073248b..b6a1b5334565 100644
--- a/net/ipv4/inet_hashtables.c
+++ b/net/ipv4/inet_hashtables.c
@@ -477,6 +477,7 @@ bool inet_ehash_insert(struct sock *sk, struct sock *osk)
struct inet_ehash_bucket *head;
spinlock_t *lock;
bool ret = true;
+   struct sock *reqsk = NULL;
 
WARN_ON_ONCE(!sk_unhashed(sk));
 
@@ -486,6 +487,18 @@ bool inet_ehash_insert(struct sock *sk, struct sock *osk)
lock = inet_ehash_lockp(hashinfo, sk->sk_hash);
 
spin_lock(lock);
+   if (!osk)
+   reqsk = __inet_lookup_established(sock_net(sk), _hashinfo,
+   sk->sk_daddr, 
sk->sk_dport,
+   sk->sk_rcv_saddr, 
sk->sk_num,
+

Re: [PATCH 2/2] edac: add support for Amazon's Annapurna Labs EDAC

[Borislav Petkov]

On Wed, Jun 12, 2019 at 08:25:52AM +1000, Benjamin Herrenschmidt wrote:
> Yes, we would be in a world of pain already if tracepoints couldn't
> handle concurrency :-)

Right, lockless buffer and the whole shebang :)

> Sort-of... I still don't see a race in what we propose but I might be
> missing something subtle. We are talking about two drivers for two
> different IP blocks updating different counters etc...

If you do only *that* you should be fine. That should technically be ok.

I still think, though, that the sensible thing to do is have one
platform driver which concentrates all RAS functionality. It is the
more sensible design and takes care of potential EDAC shortcomings and
the need to communicate between the different logging functionality,
as in, for example, "I had so many errors, lemme go and increase DRAM
scrubber frequency." For example. And all the other advantages of having
everything in a single driver.

And x86 already does that - we even have a single driver for all AMD
platforms - amd64_edac. Intel has a couple but there's still a lot of
sharing.

But apparently ARM folks want to have one driver per IP block. And we
have this discussion each time a new vendor decides to upstream its
driver. And there's no shortage of vendors in ARM-land trying to do
that.

James and I have tried to come up with a nice scheme to make that work
on ARM and he has an example prototype here:

http://www.linux-arm.org/git?p=linux-jm.git;a=shortlog;h=refs/heads/edac_dummy/v1

to show how it could look like.

But I'm slowly growing a serious aversion against having this very same
discussion each time an ARM vendor sends a driver. And that happens
pretty often nowadays.

-- 
Regards/Gruss,
Boris.

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

[PATCH] media: ttpci: Fix build error without RC_CORE

[YueHaibing]

If RC_CORE is not set, building fails:

drivers/media/pci/ttpci/av7110_ir.o: In function `av7110_ir_init':
av7110_ir.c:(.text+0x1b0): undefined reference to `rc_allocate_device'
av7110_ir.c:(.text+0x2c1): undefined reference to `rc_register_device'
av7110_ir.c:(.text+0x2dc): undefined reference to `rc_free_device'

Reported-by: Hulk Robot 
Fixes: 71f49a8bf5c5 ("media: ttpci: use rc-core for the IR receiver")
Signed-off-by: YueHaibing 
---
 drivers/media/pci/ttpci/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/ttpci/Kconfig b/drivers/media/pci/ttpci/Kconfig
index d96d4fa..b705631 100644
--- a/drivers/media/pci/ttpci/Kconfig
+++ b/drivers/media/pci/ttpci/Kconfig
@@ -7,7 +7,7 @@ config DVB_AV7110
depends on DVB_CORE && PCI && I2C
select TTPCI_EEPROM
select VIDEO_SAA7146_VV
-   select DVB_AV7110_IR if INPUT_EVDEV=y || INPUT_EVDEV=DVB_AV7110
+   select DVB_AV7110_IR if RC_CORE=DVB_AV7110 && (INPUT_EVDEV=y || 
INPUT_EVDEV=DVB_AV7110)
depends on VIDEO_DEV# dependencies of VIDEO_SAA7146_VV
select DVB_VES1820 if MEDIA_SUBDRV_AUTOSELECT
select DVB_VES1X93 if MEDIA_SUBDRV_AUTOSELECT
-- 
2.7.4

Re: [RFC PATCH] x86/cpufeatures: Enumerate new AVX512 bfloat16 instructions

[Fenghua Yu]

On Tue, Jun 11, 2019 at 09:47:02PM +0200, Borislav Petkov wrote:
> On Tue, Jun 11, 2019 at 11:19:20AM -0700, Fenghua Yu wrote:
> > So can I re-organize word 11 and 12 as follows?
> > 
> > 1. Change word 11 to host scattered features.
> > 2. Move the previos features in word 11 and word 12 to word 11:
> > /*
> >  * Extended auxiliary flags: Linux defined - For features scattered in 
> > various
> >  * CPUID levels and sub-leaves like CPUID level 7 and sub-leaf 1, etc, word 
> > 19.
> >  */
> > #define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */
> > #define X86_FEATURE_CQM_OCCUP_LLC   (11*32+ 1) /* LLC occupancy 
> > monitoring */
> > #define X86_FEATURE_CQM_MBM_TOTAL   (11*32+ 2) /* LLC Total MBM 
> > monitoring */
> > #define X86_FEATURE_CQM_MBM_LOCAL   (11*32+ 3) /* LLC Local MBM 
> > monitoring */
> 
> Yap.
> 
> > 3. Change word 12 to host CPUID.(EAX=7,ECX=1):EAX:
> > /* Intel-defined CPU features, CPUID level 0x7:1 (EAX), word 12 */
> > #define X86_FEATURE_AVX512_BF16 (12*32+ 0) /* BFLOAT16 instructions 
> > */
> 
> This needs to be (12*32+ 5) if word 12 is going to map leaf
> CPUID.(EAX=7,ECX=1):EAX.
> 
> At least judging from the arch extensions doc which lists EAX as:
> 
> Bits 04-00: Reserved.
> Bit 05: AVX512_BF16. Vector Neural Network Instructions supporting BFLOAT16 
> inputs and conversion instructions from IEEE single precision.
> Bits 31-06: Reserved.
> 
> > 4. Do other necessary changes to match the new word 11 and word 12.
> 
> But split in two patches: first does steps 1+2, second patch adds the
> new leaf to word 12.

Currently KVM doesn't simulate scattered features (the ones in CPUID_LNX_*
in cpuid_leafs) as reverse_cpuid[] doesn't contain CPUID_LNX_*.

After the X86_FEATURES_CQM_* features are changed to scattered features,
they will not be simulated by KVM any more as CPUID_F_0_EDX and CPUID_F_1_EDX
are removed.

Should patch #1 simulate X86_FEATURE_CQM_* in KVM? Or let KVM guys handle
the scattered features?

Thanks.

-Fenghua

[PATCH 2/2] soc: imx8: Use existing of_root directly

[Anson . Huang]

From: Anson Huang 

There is common of_root for reference, no need to find it
from DT again, use of_root directly to make driver simple.

Signed-off-by: Anson Huang 
---
 drivers/soc/imx/soc-imx8.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index 86b925a..a632083 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -100,7 +100,6 @@ static int __init imx8_soc_init(void)
 {
struct soc_device_attribute *soc_dev_attr;
struct soc_device *soc_dev;
-   struct device_node *root;
const struct of_device_id *id;
u32 soc_rev = 0;
const struct imx8_soc_data *data;
@@ -112,12 +111,11 @@ static int __init imx8_soc_init(void)
 
soc_dev_attr->family = "Freescale i.MX";
 
-   root = of_find_node_by_path("/");
-   ret = of_property_read_string(root, "model", _dev_attr->machine);
+   ret = of_property_read_string(of_root, "model", _dev_attr->machine);
if (ret)
goto free_soc;
 
-   id = of_match_node(imx8_soc_match, root);
+   id = of_match_node(imx8_soc_match, of_root);
if (!id) {
ret = -ENODEV;
goto free_soc;
@@ -145,8 +143,6 @@ static int __init imx8_soc_init(void)
goto free_rev;
}
 
-   of_node_put(root);
-
if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT))
platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0);
 
@@ -156,7 +152,6 @@ static int __init imx8_soc_init(void)
kfree(soc_dev_attr->revision);
 free_soc:
kfree(soc_dev_attr);
-   of_node_put(root);
return ret;
 }
 device_initcall(imx8_soc_init);
-- 
2.7.4

[PATCH 1/2] soc: imx8: Fix potential kernel dump in error path

[Anson . Huang]

From: Anson Huang 

When SoC's revision value is 0, SoC driver will print out
"unknown" in sysfs's revision node, this "unknown" is a
static string which can NOT be freed, this will caused below
kernel dump in later error path which calls kfree:

kernel BUG at mm/slub.c:3942!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 1 Comm: swapper/0 Not tainted 
5.2.0-rc4-next-20190611-00023-g705146c-dirty #2197
Hardware name: NXP i.MX8MQ EVK (DT)
pstate: 6005 (nZCv daif -PAN -UAO)
pc : kfree+0x170/0x1b0
lr : imx8_soc_init+0xc0/0xe4
sp : 1003bd10
x29: 1003bd10 x28: 1121e0a0
x27: 11482000 x26: 1117068c
x25: 1121e100 x24: 11482000
x23: 10fe2b58 x22: 111b9ab0
x21: 8000bd9dfba0 x20: 111b9b70
x19: 7e43f880 x18: 1000
x17: 10d05fa0 x16: 122e
x15: 0140 x14: 3036
x13: 8000b94b5bb0 x12: 0038
x11:  x10: 
x9 : 0003 x8 : 8000b9488147
x7 : 1003bc00 x6 : 
x5 : 0003 x4 : 0003
x3 : 0003 x2 : b8793acd604edf00
x1 : 7e43f880 x0 : 7e43f888
Call trace:
 kfree+0x170/0x1b0
 imx8_soc_init+0xc0/0xe4
 do_one_initcall+0x58/0x1b8
 kernel_init_freeable+0x1cc/0x288
 kernel_init+0x10/0x100
 ret_from_fork+0x10/0x18

This patch fixes this potential kernel dump when a chip's
revision is "unknown", it is done by always printing out
the revision value.

Fixes: a7e26f356ca1 ("soc: imx: Add generic i.MX8 SoC driver")
Signed-off-by: Anson Huang 
---
 drivers/soc/imx/soc-imx8.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/soc/imx/soc-imx8.c b/drivers/soc/imx/soc-imx8.c
index 02309a2..86b925a 100644
--- a/drivers/soc/imx/soc-imx8.c
+++ b/drivers/soc/imx/soc-imx8.c
@@ -96,11 +96,6 @@ static const struct of_device_id imx8_soc_match[] = {
{ }
 };
 
-#define imx8_revision(soc_rev) \
-   soc_rev ? \
-   kasprintf(GFP_KERNEL, "%d.%d", (soc_rev >> 4) & 0xf,  soc_rev & 0xf) : \
-   "unknown"
-
 static int __init imx8_soc_init(void)
 {
struct soc_device_attribute *soc_dev_attr;
@@ -135,7 +130,10 @@ static int __init imx8_soc_init(void)
soc_rev = data->soc_revision();
}
 
-   soc_dev_attr->revision = imx8_revision(soc_rev);
+   soc_dev_attr->revision = kasprintf(GFP_KERNEL,
+  "%d.%d",
+  (soc_rev >> 4) & 0xf,
+  soc_rev & 0xf);
if (!soc_dev_attr->revision) {
ret = -ENOMEM;
goto free_soc;
-- 
2.7.4

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Benjamin Herrenschmidt]

On Tue, 2019-06-11 at 20:52 -0500, Larry Finger wrote:
> On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:
> > On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:
> > > b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
> > > 0x3fff,
> > > min_mask = 0x5000/0x5000, dma bits = 0x1f
> > 
> > Ugh ? A mask with holes in it ? That's very wrong... That min_mask is
> > bogus.
> 
> I agree, but that is not likely serious as most systems will have enough 
> memory 
> that the max_pfn term will be much larger than the initial min_mask, and 
> min_mask will be unchanged by the min function. 

Well no... it's too much memory that is the problem. If min_mask is
bogus though it will cause problem later too, so one should look into
it.

> In addition, min_mask is not 
> used beyond this routine, and then only to decide if direct dma is supported. 
> The following patch generates masks with no holes, but I cannot see that it 
> is 
> needed.

The right fix is to round up max_pfn to a power of 2, something like

min_mask = min_t(u64, min_mask, (roundup_pow_of_two(max_pfn - 1)) <<
PAGE_SHIFT) 

> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 2c2772e9702a..e3edd4f29e80 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -384,7 +384,8 @@ int dma_direct_supported(struct device *dev, u64 mask)
>  else
>  min_mask = DMA_BIT_MASK(32);
> 
> -   min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
> +   min_mask = min_t(u64, min_mask, ((max_pfn - 1) << PAGE_SHIFT) |
> +DMA_BIT_MASK(PAGE_SHIFT));
> 
>  /*
>   * This check needs to be against the actual bit mask value, so
> 
> 
> Larry

RE: [RFC PATCH] x86/cpufeatures: Enumerate new AVX512 bfloat16 instructions

[Yu, Fenghua]

> On Tuesday, June 11, 2019 3:28 PM, Fenghua Yu wrote:
> On Tue, Jun 11, 2019 at 09:47:02PM +0200, Borislav Petkov wrote:
> > On Tue, Jun 11, 2019 at 11:19:20AM -0700, Fenghua Yu wrote:
> > > So can I re-organize word 11 and 12 as follows?
> > >
> > > 1. Change word 11 to host scattered features.
> > > 2. Move the previos features in word 11 and word 12 to word 11:
> > > /*
> > >  * Extended auxiliary flags: Linux defined - For features scattered
> > > in various
> > >  * CPUID levels and sub-leaves like CPUID level 7 and sub-leaf 1, etc,
> word 19.
> > >  */
> > > #define X86_FEATURE_CQM_LLC (11*32+ 0) /* LLC QoS if 1 */
> > > #define X86_FEATURE_CQM_OCCUP_LLC   (11*32+ 1) /* LLC
> occupancy monitoring */
> > > #define X86_FEATURE_CQM_MBM_TOTAL   (11*32+ 2) /* LLC Total
> MBM monitoring */
> > > #define X86_FEATURE_CQM_MBM_LOCAL   (11*32+ 3) /* LLC Local
> MBM monitoring */
> >
> > Yap.
> >
> > > 3. Change word 12 to host CPUID.(EAX=7,ECX=1):EAX:
> > > /* Intel-defined CPU features, CPUID level 0x7:1 (EAX), word 12 */
> > > #define X86_FEATURE_AVX512_BF16 (12*32+ 0) /* BFLOAT16
> instructions */
> >
> > This needs to be (12*32+ 5) if word 12 is going to map leaf
> > CPUID.(EAX=7,ECX=1):EAX.
> >
> > At least judging from the arch extensions doc which lists EAX as:
> >
> > Bits 04-00: Reserved.
> > Bit 05: AVX512_BF16. Vector Neural Network Instructions supporting
> BFLOAT16 inputs and conversion instructions from IEEE single precision.
> > Bits 31-06: Reserved.
> 
> Yes, you are absolutely right. I'll defint it as (12*32+ 5).
> 
> >
> > > 4. Do other necessary changes to match the new word 11 and word 12.
> >
> > But split in two patches: first does steps 1+2, second patch adds the
> > new leaf to word 12.
> 
> There are two varialbes defined in cpuinfo_x86: x86_cache_max_rmid and
> x86_cache_occ_scale. c->x86_cache_max_rmid is read from CPUID.0xf.1:ECX
> and c->x86_cache_occ_scale is read from CPUID.0xf.1:EBX.
> 
> After getting X86_FEATURE_CQM_* from scattered, the two variables need
> to be read from CPUID again. So the code of reading the two variables need
> to be moved from before init_scattered_cpuid_features(c) to after the
> function. This make the get_cpu_cap() code awkward.
> 
> And the two variables are ONLY used in resctrl monitoring configuration.
> There is no need to store them in cpuinfo_x86 on each CPU.
> 
> I'm thinking to simplify and clean this part of code:
> 
> 1. In patch #1:
> - remove the definitions of x86_cache_max_rmid and x86_cache_occ_scale
> from cpuinfo_x86
> - remove assignment of c->x86_cache_max_rmid and c-
> >x86_cache_occ_scale from get_cpu_cap(c)
> - get r->mon_scale and r->num_rmid in rdt_get_mon_l3_config(r) directly
> from CPUID.0xf.1:EBX and CPUID.0xf.1:ECX.
> 2. In patch #2: do steps 1+2 to recycle word 11. After patch #1, I can totally
> remove the code to get c->x86_cache_max_rmd and
> c->x86_cache_occ_scale in get_cpu_cap(c). And patch #2 is cleaner.
> 3. In patch #3: add new word 12 to host CPUID.7.1:EAX
> 
> Do you think the patch #1 is necessary and this is a right patch set?

My bad. I studied a bit more and found the patch #1 is not needed. Please 
ignore my last email.
 
Thanks.
 
-Fenghua

[PATCH] ipmi: ipmb: Fix build error while CONFIG_I2C is set to m

[YueHaibing]

If CONFIG_I2C is m and CONFIG_I2C_SLAVE is y,
building with CONFIG_IPMB_DEVICE_INTERFACE setting to
y will fail:

drivers/char/ipmi/ipmb_dev_int.o: In function `ipmb_remove':
ipmb_dev_int.c: undefined reference to `i2c_slave_unregister'
drivers/char/ipmi/ipmb_dev_int.o: In function `ipmb_write':
ipmb_dev_int.c: undefined reference to `i2c_smbus_write_block_data'
drivers/char/ipmi/ipmb_dev_int.o: In function `ipmb_probe':
ipmb_dev_int.c: undefined reference to `i2c_slave_register'
drivers/char/ipmi/ipmb_dev_int.o: In function `ipmb_driver_init':
ipmb_dev_int.c: undefined reference to `i2c_register_driver'
drivers/char/ipmi/ipmb_dev_int.o: In function `ipmb_driver_exit':
ipmb_dev_int.c: undefined reference to `i2c_del_driver'

Add I2C Kconfig dependency to fix this.

Reported-by: Hulk Robot 
Fixes: 51bd6f291583 ("Add support for IPMB driver")
Signed-off-by: YueHaibing 
---
 drivers/char/ipmi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
index 987191b..4bad061 100644
--- a/drivers/char/ipmi/Kconfig
+++ b/drivers/char/ipmi/Kconfig
@@ -135,6 +135,7 @@ config ASPEED_BT_IPMI_BMC
 
 config IPMB_DEVICE_INTERFACE
tristate 'IPMB Interface handler'
+   depends on I2C
depends on I2C_SLAVE
help
  Provides a driver for a device (Satellite MC) to
-- 
2.7.4

Re: [PATCH] dt-bindings: gpio: Convert Arm PL061 to json-schema

[Viresh Kumar]

On 11-06-19, 13:54, Rob Herring wrote:
> On Mon, May 27, 2019 at 12:41 AM Viresh Kumar  wrote:
> > I checked SPEAr and it is missing interrupt-controller at few places and 
> > clocks
> > everywhere. Missing clocks should be fine as SPEAr doesn't get clocks from 
> > DT.
> 
> Clocks not from DT was supposed to be a transitional thing...

Right, but by the time I left ST in 2012, mainline clock's DT support
wasn't there and the SPEAr core team got fired soon after that. No one
was left in ST to do the porting, but there are still people using the
SPEAr boards and there are products in market, so we can't delete the
platform as well.

So, no one is going to add clock DT support now.

> > And interrupt-controller can be just added, I don't think there would be any
> > platform dependent side-affects ?
> 
> There shouldn't be.

Okay, will send a patch for that then.

-- 
viresh

Re: linux-next 20190611: objtool warning

[Randy Dunlap]

On 6/11/19 7:52 PM, Josh Poimboeuf wrote:
> On Tue, Jun 11, 2019 at 06:59:22PM -0700, Randy Dunlap wrote:
>> Hi,
>>
>> New warning AFAIK:
>>
>> drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0x11f: sibling 
>> call from callable instruction with modified stack frame
> 
> I'm getting a different warning:
> 
>   drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't 
> find jump dest instruction at .text+0x93a
> 
> But I bet the root cause is the same.
> 
> This fixes it for me:
> 
> From: Josh Poimboeuf 
> Subject: [PATCH] hwmon/smsc47m1: Fix objtool warning caused by undefined 
> behavior
> 
> Objtool is reporting the following warning:
> 
>   drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't 
> find jump dest instruction at .text+0x93a
> 
> It's apparently caused by
> 
>   2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
> warnings")
> 
> which is somehow convincing GCC to add a jump past the end of the
> function:
> 
>   793:   45 85 edtest   %r13d,%r13d
>   796:   0f 88 9e 01 00 00   js 93a 
>   ...
>   930:   e9 5e fe ff ff  jmpq   793 
>   935:   e8 00 00 00 00  callq  93a 
>   936: R_X86_64_PLT32 __stack_chk_fail-0x4
>   
> 
> I suppose this falls under the category of undefined behavior, so we
> probably can't call it a GCC bug.  But if the value of "nr" were out of
> range somehow then it would start executing random code.  Use a runtime
> BUG() assertion to avoid undefined behavior.
> 
> Fixes: 2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
> warnings")
> Reported-by: Randy Dunlap 
> Signed-off-by: Josh Poimboeuf 

Yes, that works for me.  Thanks.

Acked-by: Randy Dunlap 

> ---
>  drivers/hwmon/smsc47m1.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
> index 6d366c9cb906..b637836b58a1 100644
> --- a/drivers/hwmon/smsc47m1.c
> +++ b/drivers/hwmon/smsc47m1.c
> @@ -352,7 +352,7 @@ static ssize_t fan_div_store(struct device *dev,
>   smsc47m1_write_value(data, SMSC47M2_REG_FANDIV3, tmp);
>   break;
>   default:
> - unreachable();
> + BUG();
>   }
>  
>   /* Preserve fan min */
> 


-- 
~Randy

[PATCH 2/2] mt76: mt7615: update peer's bssid when state transition changes

[Ryder Lee]

Driver should update peer's bssid and bss information when
state transition changes.

Signed-off-by: Ryder Lee 
---
 .../net/wireless/mediatek/mt76/mt7615/main.c  |  5 +-
 .../net/wireless/mediatek/mt76/mt7615/mcu.c   | 49 ++-
 2 files changed, 27 insertions(+), 27 deletions(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index d21407ddda31..e0824392c019 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -283,9 +283,8 @@ static void mt7615_bss_info_changed(struct ieee80211_hw *hw,
 
mutex_lock(>mt76.mutex);
 
-   /* TODO: sta mode connect/disconnect
-* BSS_CHANGED_ASSOC | BSS_CHANGED_BSSID
-*/
+   if (changed & BSS_CHANGED_ASSOC)
+   mt7615_mcu_set_bss_info(dev, vif, info->assoc);
 
/* TODO: update beacon content
 * BSS_CHANGED_BEACON
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index e82086eb8aa4..8fc12cd37906 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -741,17 +741,6 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
u8 *buf, *data, tx_wlan_idx = 0;
struct req_hdr *hdr;
 
-   if (en) {
-   len += sizeof(struct bss_info_omac);
-   features |= BIT(BSS_INFO_OMAC);
-   if (mvif->omac_idx > EXT_BSSID_START) {
-   len += sizeof(struct bss_info_ext_bss);
-   features |= BIT(BSS_INFO_EXT_BSS);
-   ntlv++;
-   }
-   ntlv++;
-   }
-
switch (vif->type) {
case NL80211_IFTYPE_AP:
case NL80211_IFTYPE_MESH_POINT:
@@ -759,22 +748,23 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
conn_type = CONNECTION_INFRA_AP;
break;
case NL80211_IFTYPE_STATION: {
-   struct ieee80211_sta *sta;
-   struct mt7615_sta *msta;
-
-   rcu_read_lock();
-
-   sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
-   if (!sta) {
+   /* TODO: enable BSS_INFO_UAPSD & BSS_INFO_PM */
+   if (en) {
+   struct ieee80211_sta *sta;
+   struct mt7615_sta *msta;
+
+   rcu_read_lock();
+   sta = ieee80211_find_sta(vif, vif->bss_conf.bssid);
+   if (!sta) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+
+   msta = (struct mt7615_sta *)sta->drv_priv;
+   tx_wlan_idx = msta->wcid.idx;
rcu_read_unlock();
-   return -EINVAL;
}
-
-   msta = (struct mt7615_sta *)sta->drv_priv;
-   tx_wlan_idx = msta->wcid.idx;
conn_type = CONNECTION_INFRA_STA;
-
-   rcu_read_unlock();
break;
}
default:
@@ -782,6 +772,17 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
break;
}
 
+   if (en) {
+   len += sizeof(struct bss_info_omac);
+   features |= BIT(BSS_INFO_OMAC);
+   if (mvif->omac_idx > EXT_BSSID_START) {
+   len += sizeof(struct bss_info_ext_bss);
+   features |= BIT(BSS_INFO_EXT_BSS);
+   ntlv++;
+   }
+   ntlv++;
+   }
+
buf = kzalloc(len, GFP_KERNEL);
if (!buf)
return -ENOMEM;
-- 
2.18.0

[PATCH v2] mt76: mt7615: add support for per-chain signal strength reporting

[Ryder Lee]

Fill in RX status->chain_signal to avoid empty value.

Signed-off-by: Ryder Lee 
---
Changes since v2 - correct calculation sequence
---
 .../net/wireless/mediatek/mt76/mt7615/mac.c   | 30 ++-
 .../net/wireless/mediatek/mt76/mt7615/mac.h   |  5 
 2 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
index b60d42b5923d..2f49a99e77b1 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.c
@@ -13,6 +13,11 @@
 #include "../dma.h"
 #include "mac.h"
 
+static inline s8 to_rssi(u32 field, u32 rxv)
+{
+   return (FIELD_GET(field, rxv) - 220) / 2;
+}
+
 static struct mt76_wcid *mt7615_rx_get_wcid(struct mt7615_dev *dev,
u8 idx, bool unicast)
 {
@@ -120,6 +125,7 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct 
sk_buff *skb)
if (rxd0 & MT_RXD0_NORMAL_GROUP_3) {
u32 rxdg0 = le32_to_cpu(rxd[0]);
u32 rxdg1 = le32_to_cpu(rxd[1]);
+   u32 rxdg3 = le32_to_cpu(rxd[3]);
u8 stbc = FIELD_GET(MT_RXV1_HT_STBC, rxdg0);
bool cck = false;
 
@@ -169,7 +175,29 @@ int mt7615_mac_fill_rx(struct mt7615_dev *dev, struct 
sk_buff *skb)
 
status->enc_flags |= RX_ENC_FLAG_STBC_MASK * stbc;
 
-   /* TODO: RSSI */
+   status->chains = dev->mt76.antenna_mask;
+   status->chain_signal[0] = to_rssi(MT_RXV4_RCPI0, rxdg3);
+   status->chain_signal[1] = to_rssi(MT_RXV4_RCPI1, rxdg3);
+   status->chain_signal[2] = to_rssi(MT_RXV4_RCPI2, rxdg3);
+   status->chain_signal[3] = to_rssi(MT_RXV4_RCPI3, rxdg3);
+   status->signal = status->chain_signal[0];
+
+   switch (status->chains) {
+   case 0xf:
+   status->signal = max(status->signal,
+status->chain_signal[3]);
+   /* fall through */
+   case 0x7:
+   status->signal = max(status->signal,
+status->chain_signal[2]);
+   /* fall through */
+   case 0x3:
+   status->signal = max(status->signal,
+status->chain_signal[1]);
+   break;
+   default:
+   break;
+   }
rxd += 6;
if ((u8 *)rxd - skb->data >= skb->len)
return -EINVAL;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h 
b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
index 18ad4b8a3807..b00ce8db58e9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mac.h
@@ -98,6 +98,11 @@ enum rx_pkt_type {
 #define MT_RXV2_GROUP_ID   GENMASK(26, 21)
 #define MT_RXV2_LENGTH GENMASK(20, 0)
 
+#define MT_RXV4_RCPI3  GENMASK(31, 24)
+#define MT_RXV4_RCPI2  GENMASK(23, 16)
+#define MT_RXV4_RCPI1  GENMASK(15, 8)
+#define MT_RXV4_RCPI0  GENMASK(7, 0)
+
 enum tx_header_format {
MT_HDR_FORMAT_802_3,
MT_HDR_FORMAT_CMD,
-- 
2.18.0

[PATCH 1/2] mt76: mt7615: fix incorrect settings in mesh mode

[Ryder Lee]

Fix wrong settings that will drop packets due to hardware's RX table
searching flow.

Fixes: f072c7ba2150 ("mt76: mt7615: enable support for mesh")
Signed-off-by: Ryder Lee 
---
 drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c 
b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 76431d00a8ac..e82086eb8aa4 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -970,7 +970,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct 
ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
-   .rca1 = vif->type == NL80211_IFTYPE_STATION,
+   .rca1 = vif->type != NL80211_IFTYPE_AP,
.rca2 = 1,
.rv = 1,
},
-- 
2.18.0

Re: Getting empty callchain from perf_callchain_kernel()

[Josh Poimboeuf]

On Fri, May 24, 2019 at 10:53:19AM +0200, Peter Zijlstra wrote:
> > For ORC, I'm thinking we may be able to just require that all generated
> > code (BPF and others) always use frame pointers.  Then when ORC doesn't
> > recognize a code address, it could try using the frame pointer as a
> > fallback.
> 
> Yes, this seems like a sensible approach. We'd also have to audit the
> ftrace and kprobe trampolines, IIRC they only do framepointer setup for
> CONFIG_FRAME_POINTER currently, which should be easy to fix (after the
> patches I have to fix the FP generation in the first place:
> 
>   
> https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?h=x86/wip

Right now, ftrace has a special hook in the ORC unwinder
(orc_ftrace_find).  It would be great if we could get rid of that in
favor of the "always use frame pointers" approach.  I'll hold off on
doing the kpatch/kprobe trampoline conversions in my patches since it
would conflict with yours.

Though, hm, because of pt_regs I guess ORC would need to be able to
decode an encoded frame pointer?  I was hoping we could leave those
encoded frame pointers behind in CONFIG_FRAME_POINTER-land forever...

Here are my latest BPF unwinder patches in case anybody wants a sneak
peek:

  
https://git.kernel.org/pub/scm/linux/kernel/git/jpoimboe/linux.git/log/?h=bpf-orc-fix

-- 
Josh

Re: linux-next 20190611: objtool warning

[Josh Poimboeuf]

On Tue, Jun 11, 2019 at 06:59:22PM -0700, Randy Dunlap wrote:
> Hi,
> 
> New warning AFAIK:
> 
> drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0x11f: sibling 
> call from callable instruction with modified stack frame

I'm getting a different warning:

  drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't find 
jump dest instruction at .text+0x93a

But I bet the root cause is the same.

This fixes it for me:

From: Josh Poimboeuf 
Subject: [PATCH] hwmon/smsc47m1: Fix objtool warning caused by undefined 
behavior

Objtool is reporting the following warning:

  drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0xb6: can't find 
jump dest instruction at .text+0x93a

It's apparently caused by

  2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
warnings")

which is somehow convincing GCC to add a jump past the end of the
function:

  793:   45 85 edtest   %r13d,%r13d
  796:   0f 88 9e 01 00 00   js 93a 
  ...
  930:   e9 5e fe ff ff  jmpq   793 
  935:   e8 00 00 00 00  callq  93a 
936: R_X86_64_PLT32 __stack_chk_fail-0x4
  

I suppose this falls under the category of undefined behavior, so we
probably can't call it a GCC bug.  But if the value of "nr" were out of
range somehow then it would start executing random code.  Use a runtime
BUG() assertion to avoid undefined behavior.

Fixes: 2cf6745e69d1 ("hwmon: (smsc47m1) fix (suspicious) outside array bounds 
warnings")
Reported-by: Randy Dunlap 
Signed-off-by: Josh Poimboeuf 
---
 drivers/hwmon/smsc47m1.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hwmon/smsc47m1.c b/drivers/hwmon/smsc47m1.c
index 6d366c9cb906..b637836b58a1 100644
--- a/drivers/hwmon/smsc47m1.c
+++ b/drivers/hwmon/smsc47m1.c
@@ -352,7 +352,7 @@ static ssize_t fan_div_store(struct device *dev,
smsc47m1_write_value(data, SMSC47M2_REG_FANDIV3, tmp);
break;
default:
-   unreachable();
+   BUG();
}
 
/* Preserve fan min */
-- 
2.20.1

Re: [PATCH 4/4] mm: shrinker: make shrinker not depend on memcg kmem

[Kirill A. Shutemov]

On Fri, Jun 07, 2019 at 02:07:39PM +0800, Yang Shi wrote:
> Currently shrinker is just allocated and can work when memcg kmem is
> enabled.  But, THP deferred split shrinker is not slab shrinker, it
> doesn't make too much sense to have such shrinker depend on memcg kmem.
> It should be able to reclaim THP even though memcg kmem is disabled.
> 
> Introduce a new shrinker flag, SHRINKER_NONSLAB, for non-slab shrinker,
> i.e. THP deferred split shrinker.  When memcg kmem is disabled, just
> such shrinkers can be called in shrinking memcg slab.

Looks like it breaks bisectability. It has to be done before makeing
shrinker memcg-aware, hasn't it?

-- 
 Kirill A. Shutemov

Re: [PATCH v2 3/4] perf augmented_raw_syscalls: Support arm64 raw syscalls

[Arnaldo Carvalho de Melo]

Em Tue, Jun 11, 2019 at 12:18:31PM +0800, Leo Yan escreveu:
> On Mon, Jun 10, 2019 at 03:47:54PM -0300, Arnaldo Carvalho de Melo wrote:
> 
> [...]
> 
> > > > I tested with the lastest perf/core branch which contains the patch:
> > > > 'perf augmented_raw_syscalls: Tell which args are filenames and how
> > > > many bytes to copy' and got the error as below:
> > > > 
> > > > # perf trace -e string -e 
> > > > /mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c
> > > > Error:  Invalid syscall access, chmod, chown, creat, futimesat, lchown, 
> > > > link, lstat, mkdir, mknod, newfstatat, open, readlink, rename,
> > > > rmdir, stat, statfs, symlink, truncate, unlink
> > 
> > Humm, I think that we can just make the code that parses the
> > tools/perf/trace/strace/groups/string file to ignore syscalls it can't
> > find in the syscall_tbl, i.e. trace those if they exist in the arch.
> 
> Agree.
> 
> > > > Hint:   try 'perf list syscalls:sys_enter_*'
> > > > Hint:   and: 'man syscalls'
> > > > 
> > > > So seems mksyscalltbl has not included completely for syscalls, I
> > > > use below command to generate syscalltbl_arm64[] array and it don't
> > > > include related entries for access, chmod, chown, etc ...
> > 
> > So, we need to investigate why is that these are missing, good thing we
> > have this 'strings' group :-)
> > 
> > > > You could refer the generated syscalltbl_arm64 in:
> > > > http://paste.ubuntu.com/p/8Bj7Jkm2mP/
> > > 
> > > After digging into this issue on Arm64, below is summary info:
> > > 
> > > - arm64 uses the header include/uapi/linux/unistd.h to define system
> > >   call numbers, in this header some system calls are not defined (I
> > >   think the reason is these system calls are obsolete at the end) so the
> > >   corresponding strings are missed in the array syscalltbl_native,
> > >   for arm64 the array is defined in the file:
> > >   tools/perf/arch/arm64/include/generated/asm/syscalls.c.
> > 
> > Yeah, I looked at the 'access' case and indeed it is not present in
> > include/uapi/asm-generic/unistd.h, which is the place
> > include/uapi/linux/unistd.h ends up.
> > 
> > Ok please take a look at the patch at the end of this message, should be ok?
> > 
> > I tested it by changing the strace/gorups/string file to have a few
> > unknown syscalls, running it with -v we see:
> > 
> > [root@quaco perf]# perf trace -v -e string ls
> > Skipping unknown syscalls: access99, acct99, add_key99
> > 
> > normal operation not considering those unknown syscalls.
> 
> I did testing with the patch, but it failed after I added eBPF event
> with below command, I even saw segmentation fault; please see below
> inline comments.
> 
>   perf --debug verbose=10 trace -e string -e \
> 
> /mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c
> 
> [...]
> 
> > commit e0b34a78c4ed0a6422f5b2dafa0c8936e537ee41
> > Author: Arnaldo Carvalho de Melo 
> > Date:   Mon Jun 10 15:37:45 2019 -0300
> > 
> > perf trace: Skip unknown syscalls when expanding strace like syscall 
> > groups
> > 
> > We have $INSTALL_DIR/share/perf-core/strace/groups/string files with
> > syscalls that should be selected when 'string' is used, meaning, in this
> > case, syscalls that receive as one of its arguments a string, like a
> > pathname.
> > 
> > But those were first selected and tested on x86_64, and end up failing
> > in architectures where some of those syscalls are not available, like
> > the 'access' syscall on arm64, which makes using 'perf trace -e string'
> > in such archs to fail.
> > 
> > Since this the routine doing the validation is used only when reading
> > such files, do not fail when some syscall is not found in the
> > syscalltbl, instead just use pr_debug() to register that in case people
> > are suspicious of problems.
> > 
> > Now using 'perf trace -e string' should work on arm64, selecting only
> > the syscalls that have a string and are available on that architecture.
> > 
> > Reported-by: Leo Yan 
> > Cc: Adrian Hunter 
> > Cc: Alexander Shishkin 
> > Cc: Alexei Starovoitov 
> > Cc: Daniel Borkmann 
> > Cc: Jiri Olsa 
> > Cc: Martin KaFai Lau 
> > Cc: Mathieu Poirier 
> > Cc: Mike Leach 
> > Cc: Namhyung Kim 
> > Cc: Song Liu 
> > Cc: Suzuki K Poulose 
> > Cc: Yonghong Song 
> > Link: 
> > https://lkml.kernel.org/n/tip-oa4c2x8p3587jme0g89fy...@git.kernel.org
> > Signed-off-by: Arnaldo Carvalho de Melo 
> > 
> > diff --git a/tools/perf/builtin-trace.c b/tools/perf/builtin-trace.c
> > index 1a2a605cf068..eb70a4b71755 100644
> > --- a/tools/perf/builtin-trace.c
> > +++ b/tools/perf/builtin-trace.c
> > @@ -1529,6 +1529,7 @@ static int trace__read_syscall_info(struct trace 
> > *trace, int id)
> >  static int trace__validate_ev_qualifier(struct trace *trace)
> >  {
> > int err = 0, i;
> > +   bool printed_invalid_prefix = 

Re: [PATCH 2/4] mm: thp: make deferred split shrinker memcg aware

[Kirill A. Shutemov]

On Fri, Jun 07, 2019 at 02:07:37PM +0800, Yang Shi wrote:
> + /*
> +  * The THP may be not on LRU at this point, e.g. the old page of
> +  * NUMA migration.  And PageTransHuge is not enough to distinguish
> +  * with other compound page, e.g. skb, THP destructor is not used
> +  * anymore and will be removed, so the compound order sounds like
> +  * the only choice here.
> +  */
> + if (PageTransHuge(page) && compound_order(page) == HPAGE_PMD_ORDER) {

What happens if the page is the same order as THP is not THP? Why removing
of destructor is required?

-- 
 Kirill A. Shutemov

Re: [PATCHv7 1/3] dt-bindings: i2c: document bindings for i2c-slave-mqueue

[Wang, Haiyue]

在 2019-06-12 07:14, Rob Herring 写道:

On Wed, Jun 05, 2019 at 09:46:49AM -0700, Eduardo Valentin wrote:

Document the i2c-slave-mqueue binding by adding
descriptor, required properties, and example.

Cc: Rob Herring 
Cc: Mark Rutland 
Cc: Wolfram Sang 
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin 
---

Changes from V6 to V7:
- none

  .../bindings/i2c/i2c-slave-mqueue.txt | 34 +++
  1 file changed, 34 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt

diff --git a/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt 
b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
new file mode 100644
index ..eb1881a4fc0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
@@ -0,0 +1,34 @@
+===
+Device Tree for I2C slave message queue backend
+===
+
+Some protocols over I2C/SMBus are designed for bi-directional transferring
+messages by using I2C Master Write protocol. This requires that both sides
+of the communication have slave addresses.

So the address 0x10 in the example below is the address of the I2C
controller?


+
+This I2C slave mqueue (message queue) is used to receive and queue

Hi Rob, This is mqueue comes from, not from specs directly.

+messages from the remote i2c intelligent device; and it will add the target
+slave address (with R/W# bit is always 0) into the message at the first byte.
+
+Links
+
+`Intelligent Platform Management Bus
+Communications Protocol Specification
+`_
+
+`Management Component Transport Protocol (MCTP)
+SMBus/I2C Transport Binding Specification
+`_
+
+Required Properties:
+- compatible   : should be "i2c-slave-mqueue"

There is no mention of mqueue (or queue) in these specs. Where does that
come from? Perhaps something more closely matching the protocol would be
better name.


+- reg  : slave address
+
+Example:
+
+i2c {

Would there be other slaves?

The common binding states 'multi-master' property should be present.

I need a more complete example.


+   slave_mqueue: i2c-slave-mqueue {
+   compatible = "i2c-slave-mqueue";
+   reg = <0x10>;


Hi Eduardo,

Looks like the slave reg missed the key value bit:


https://elinux.org/images/f/f6/ELCE15-WolframSang-ShinyNewI2CSlaveFramework.pdf

Example: reg = <(I2C_OWN_SLAVE_ADDRESS | 0x42)>;



+   };
+};
--
2.21.0

RE: 5.2-rc2: low framerate in flightgear, cpu not running at full speed, thermal related?

[Doug Smythies]

Hi,

So, currently there seems to be 3 issues in this thread
(and I am guessing a little, without definitive data):

1.) On your system Kernel 5.4-rc2 (or 4) defaults to the intel_pstate CPU 
frequency
scaling driver and the powersave governor, but kernel 4.6 defaults to the
acpi-cpufreq CPU frequency scaling driver and the ondemand governor.

Suggest to check the related kernel configuration parameters.

$ grep -A 10 -i "CPU frequency scaling drivers" .config
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
CONFIG_X86_PCC_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ_CPB=y
CONFIG_X86_POWERNOW_K8=y
CONFIG_X86_AMD_FREQ_SENSITIVITY=m
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_P4_CLOCKMOD=m

2.) With kernel 5.2-rc2 there is thermal throttling (thermald?), but for 
Kernel 4.6 it either doesn't hit the throttling threshold or is not enabled.

I don't have input here.

However note that the CPU frequency verses load graphs are quite different
between acpi-cpufreq/ondemand and intel-pstate/powersave, with higher
CPU frequencies at lower loads for the acpi-cpufreq driver and higher
CPU frequencies at higher loads for the intel_pstate driver. The crossover
point is about 35% load. So, the two driver/governors might well end up at
different operating pointing terms of CPU frequencies. I do not have energy
data for the CPU frequency verses load tests, which is really what matters.

3.) The older kernel is still using the older acpi-cpufreq stuff where
some CPU frequency memory registers show what was asked for and not what
the system is actually giving.

See below.

On 2019.06.09 04:18 Pavel Machek wrote:

> When I start flightgear, I get framerates around 20 fps and cpu at
> 3GHz:
> 
> pavel@duo:~/bt$ cat /proc/cpuinfo  | grep MHz
> cpu MHz   : 3027.471
> cpu MHz : 2981.863
> cpu MHz   : 2958.352
> cpu MHz : 2864.001
> pavel@duo:~/bt$
>
> (Ok, fgfs is really only running at single core, so why do both cores
> run at 3GHz?)

There is only 1 PLL (Phase Locked Loop) master clock generator in your
processor. Basically, the CPU with the highest frequency demand wins.
What is not shown in your data is that the not busy core is also
probably in a deep idle state for most of the time, consuming little or no
energy. Below is an example from my processor (i7-2600K) using
turbostat (note C6 is my deepest idle state, and only it is shown
for simplicity):

CoreCPU Busy%   Bzy_MHz CPU%c6  PkgTmp  PkgWatt
-   -   12.52   379974.88   54  23.87
0   0   0.05366499.89   54  23.87
0   4   0.003695
1   1   0.07367699.87
1   5   0.003667
2   2   0.09366999.78
2   6   0.003666
3   3   0.0437860.00
3   7   99.92   3800

Observe the busy core spending no time in C6, but the other 3
spend most of the time there. However, for the little time that they are active,
CPU 7 is the one demanding the high CPU frequency.

Anticipated question:
"Then why aren't all the CPU frequencies exactly the same?"
My processor's max turbo frequency is a function of how many cores
are active, and so actually varies under peak demand. Excerpt from
turbostat, not in quiet mode:

35 * 100.0 = 3500.0 MHz max turbo 4 active cores
36 * 100.0 = 3600.0 MHz max turbo 3 active cores
37 * 100.0 = 3700.0 MHz max turbo 2 active cores
38 * 100.0 = 3800.0 MHz max turbo 1 active cores

> The CPU is Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz . I guess it means
> it should be able to sustain both cores running at 2.5GHz?

No, that is more a function of your hardware's ability (or lack of) to move
the waste heat away.

> Situation is very different with v4.6 distro based kernel.
> 
> CPU MHz is only getting values round to 100MHz. It does not go above
> 2.5GHz, but it does not go below 2.5GHz under the load, either.

Yes, it is going above 2.5 GHz, see below.

> v4.6:

> cpu MHz : 2501.000
> cpu MHz : 2501.000
> cpu MHz : 2501.000
> cpu MHz : 2501.000

That seems to be the old acpi-cpufreq information,
which is telling you what it's asking for and not what
it actually is. And the "01" means it is asking for turbo
range frequencies. Example from my system, while running the
above CPU 7 busy test:

Conditions: Old kernel (4.4), acpi-cpufreq driver, ondemand gov.

doug@s15:~$ grep MHz /proc/cpuinfo
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 1600.000
cpu MHz : 3401.000

CPUs 0-6 have very little load and are asking for the minimum
available frequency. CPU 7 is asking for turbo.
The turbostat data tells a different story.

Conditions: New kernel (5.2-rc3), acpi-cpufreq driver, ondemand gov.

doug@s15:~$ grep MHz /proc/cpuinfo
cpu MHz : 3611.623
cpu MHz : 

Re: [PATCH net] mpls: fix af_mpls dependencies

[Randy Dunlap]

On 6/11/19 5:08 PM, Matteo Croce wrote:
> On Wed, Jun 12, 2019 at 1:07 AM Randy Dunlap  wrote:
>>
>> On 6/9/19 7:57 PM, David Miller wrote:
>>> From: Matteo Croce 
>>> Date: Sat,  8 Jun 2019 14:50:19 +0200
>>>
 MPLS routing code relies on sysctl to work, so let it select PROC_SYSCTL.

 Reported-by: Randy Dunlap 
 Suggested-by: David Ahern 
 Signed-off-by: Matteo Croce 
>>>
>>> Applied, thanks.
>>>
>>
>> This patch causes build errors when
>> # CONFIG_PROC_FS is not set
>> because PROC_SYSCTL depends on PROC_FS.  The build errors are not
>> in fs/proc/ but in other places in the kernel that never expect to see
>> PROC_FS not set but PROC_SYSCTL=y.
>>
> 
> Hi,
> 
> Maybe I'm missing something, if PROC_SYSCTL depends on PROC_FS, how is
> possible to have PROC_FS not set but PROC_SYSCTL=y?

When MPLS=y and MPLS_ROUTING=[y|m], MPLS_ROUTING selects PROC_SYSCTL.
That enables PROC_SYSCTL, whether PROC_FS is set/enabled or not.

There is a warning about this in Documentation/kbuild/kconfig-language.rst:

  Note:
select should be used with care. select will force
a symbol to a value without visiting the dependencies.
By abusing select you are able to select a symbol FOO even
if FOO depends on BAR that is not set.
In general use select only for non-visible symbols
(no prompts anywhere) and for symbols with no dependencies.
That will limit the usefulness but on the other hand avoid
the illegal configurations all over.


> I tried it by manually editing .config. but make oldconfig warns:
> 
> WARNING: unmet direct dependencies detected for PROC_SYSCTL
>   Depends on [n]: PROC_FS [=n]
>   Selected by [m]:
>   - MPLS_ROUTING [=m] && NET [=y] && MPLS [=y] && (NET_IP_TUNNEL [=n]
> || NET_IP_TUNNEL [=n]=n)

Yes, I get this also.

> *
> * Restart config...
> *
> *
> * Configure standard kernel features (expert users)
> *
> Configure standard kernel features (expert users) (EXPERT) [Y/?] y
>   Multiple users, groups and capabilities support (MULTIUSER) [Y/n/?] y
>   sgetmask/ssetmask syscalls support (SGETMASK_SYSCALL) [N/y/?] n
>   Sysfs syscall support (SYSFS_SYSCALL) [N/y/?] n
>   Sysctl syscall support (SYSCTL_SYSCALL) [N/y/?] (NEW)

So I still say that MPLS_ROUTING should depend on PROC_SYSCTL,
not select it.

-- 
~Randy

Re: [RFC PATCH v2 2/2] Implement sharing/unsharing of PMDs for FS/DAX

[Kirill A. Shutemov]

On Fri, Jun 07, 2019 at 12:51:03PM -0700, Larry Bassel wrote:
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 3a54c9d..1c1ed4e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -4653,9 +4653,9 @@ long hugetlb_unreserve_pages(struct inode *inode, long 
> start, long end,
>  }
>  
>  #ifdef CONFIG_ARCH_HAS_HUGE_PMD_SHARE
> -static unsigned long page_table_shareable(struct vm_area_struct *svma,
> - struct vm_area_struct *vma,
> - unsigned long addr, pgoff_t idx)
> +unsigned long page_table_shareable(struct vm_area_struct *svma,
> +struct vm_area_struct *vma,
> +unsigned long addr, pgoff_t idx)
>  {
>   unsigned long saddr = ((idx - svma->vm_pgoff) << PAGE_SHIFT) +
>   svma->vm_start;
> @@ -4678,7 +4678,7 @@ static unsigned long page_table_shareable(struct 
> vm_area_struct *svma,
>   return saddr;
>  }
>  
> -static bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
> +bool vma_shareable(struct vm_area_struct *vma, unsigned long addr)
>  {
>   unsigned long base = addr & PUD_MASK;
>   unsigned long end = base + PUD_SIZE;

This is going to be build error. mm/hugetlb.o doesn't build unlessp 
CONFIG_HUGETLBFS=y.

And I think both functions doesn't cover all DAX cases: VMA can be not
aligned (due to vm_start and/or vm_pgoff) to 2M even if the file has 2M
ranges allocated. See transhuge_vma_suitable().

And as I said before, nothing guarantees contiguous 2M ranges on backing
storage.

And in general I found piggybacking on hugetlb hacky.

The solution has to stand on its own with own justification. Saying it
worked for hugetlb and it has to work here would not fly. hugetlb is much
more restrictive on use cases. THP has more corner cases.

> diff --git a/mm/memory.c b/mm/memory.c
> index ddf20bd..1ca8f75 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -3932,6 +3932,109 @@ static vm_fault_t handle_pte_fault(struct vm_fault 
> *vmf)
>   return 0;
>  }
>  
> +#ifdef CONFIG_ARCH_HAS_HUGE_PMD_SHARE
> +static pmd_t *huge_pmd_offset(struct mm_struct *mm,
> +   unsigned long addr, unsigned long sz)
> +{
> + pgd_t *pgd;
> + p4d_t *p4d;
> + pud_t *pud;
> + pmd_t *pmd;
> +
> + pgd = pgd_offset(mm, addr);
> + if (!pgd_present(*pgd))
> + return NULL;
> + p4d = p4d_offset(pgd, addr);
> + if (!p4d_present(*p4d))
> + return NULL;
> +
> + pud = pud_offset(p4d, addr);
> + if (sz != PUD_SIZE && pud_none(*pud))
> + return NULL;
> + /* hugepage or swap? */
> + if (pud_huge(*pud) || !pud_present(*pud))
> + return (pmd_t *)pud;

So do we or do we not support PUD pages? This is just broken.
> +
> + pmd = pmd_offset(pud, addr);
> + if (sz != PMD_SIZE && pmd_none(*pmd))
> + return NULL;
> + /* hugepage or swap? */
> + if (pmd_huge(*pmd) || !pmd_present(*pmd))
> + return pmd;
> +
> + return NULL;
> +}
> +

-- 
 Kirill A. Shutemov

Re: [PATCH v5 10/15] dma: imx-sdma: add i.mx6ul/6sx compatible name

[Robin Gong]

On 2019-06-11 at 22:35 +, Rob Herring wrote:
> On Mon, 10 Jun 2019 16:17:48 +0800, yibin.g...@nxp.com wrote:
> > 
> > From: Robin Gong 
> > 
> > Add i.mx6ul and i.mx6sx compatible name in binding doc.
> > 
> > Signed-off-by: Robin Gong 
> > ---
> >  Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> Please add Acked-by/Reviewed-by tags when posting new versions.
> However,
> there's no need to repost patches *only* to add the tags. The
> upstream
> maintainer will do that for acks received on the version they apply.
> 

> If a tag was not added on purpose, please state why and what changed.
Sorry Rob...I miss your mail with 'Reviewed-by' in v2 because it slip
into 'unk Email' folder. Will add your tag in v6 if comments received
from v5

[PATCH 2/2] staging: rtl8723bs: hal: sdio_halinit: fix spaces preferred around that unary operator

[Hariprasad Kelam]

CHECK: spaces preferred around that '+' (ctx:VxV)
CHECK: spaces preferred around that '<<' (ctx:VxV)
CHECK: spaces preferred around that '|' (ctx:VxV)

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/hal/sdio_halinit.c | 92 ++--
 1 file changed, 46 insertions(+), 46 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c 
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 70f9e1d..8f1c8f0 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -112,17 +112,17 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter)
/*  all of these MUST be configured before power on */
 #ifdef CONFIG_EXT_CLK
/*  Use external crystal(XTAL) */
-   value8 = rtw_read8(padapter, REG_PAD_CTRL1_8723B+2);
+   value8 = rtw_read8(padapter, REG_PAD_CTRL1_8723B + 2);
value8 |=  BIT(7);
-   rtw_write8(padapter, REG_PAD_CTRL1_8723B+2, value8);
+   rtw_write8(padapter, REG_PAD_CTRL1_8723B + 2, value8);

/*  CLK_REQ High active or Low Active */
/*  Request GPIO polarity: */
/*  0: low active */
/*  1: high active */
-   value8 = rtw_read8(padapter, REG_MULTI_FUNC_CTRL+1);
+   value8 = rtw_read8(padapter, REG_MULTI_FUNC_CTRL + 1);
value8 |= BIT(5);
-   rtw_write8(padapter, REG_MULTI_FUNC_CTRL+1, value8);
+   rtw_write8(padapter, REG_MULTI_FUNC_CTRL + 1, value8);
 #endif /*  CONFIG_EXT_CLK */

/*  only cmd52 can be used before power on(card enable) */
@@ -137,12 +137,12 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter)
}

/*  Radio-Off Pin Trigger */
-   value8 = rtw_read8(padapter, REG_GPIO_INTM+1);
+   value8 = rtw_read8(padapter, REG_GPIO_INTM + 1);
value8 |= BIT(1); /*  Enable falling edge triggering interrupt */
-   rtw_write8(padapter, REG_GPIO_INTM+1, value8);
-   value8 = rtw_read8(padapter, REG_GPIO_IO_SEL_2+1);
+   rtw_write8(padapter, REG_GPIO_INTM + 1, value8);
+   value8 = rtw_read8(padapter, REG_GPIO_IO_SEL_2 + 1);
value8 |= BIT(1);
-   rtw_write8(padapter, REG_GPIO_IO_SEL_2+1, value8);
+   rtw_write8(padapter, REG_GPIO_IO_SEL_2 + 1, value8);

/*  Enable power down and GPIO interrupt */
value16 = rtw_read16(padapter, REG_APS_FSMCO);
@@ -203,13 +203,13 @@ static void _init_available_page_threshold(struct adapter 
*padapter, u8 numHQ, u
u16 HQ_threshold, NQ_threshold, LQ_threshold;

HQ_threshold = (numPubQ + numHQ + 1) >> 1;
-   HQ_threshold |= (HQ_threshold<<8);
+   HQ_threshold |= (HQ_threshold << 8);

NQ_threshold = (numPubQ + numNQ + 1) >> 1;
-   NQ_threshold |= (NQ_threshold<<8);
+   NQ_threshold |= (NQ_threshold << 8);

LQ_threshold = (numPubQ + numLQ + 1) >> 1;
-   LQ_threshold |= (LQ_threshold<<8);
+   LQ_threshold |= (LQ_threshold << 8);

rtw_write16(padapter, 0x218, HQ_threshold);
rtw_write16(padapter, 0x21A, NQ_threshold);
@@ -271,7 +271,7 @@ static void _InitTxBufferBoundary(struct adapter *padapter)
rtw_write8(padapter, REG_TXPKTBUF_MGQ_BDNY_8723B, txpktbuf_bndy);
rtw_write8(padapter, REG_TXPKTBUF_WMAC_LBK_BF_HD_8723B, txpktbuf_bndy);
rtw_write8(padapter, REG_TRXFF_BNDY, txpktbuf_bndy);
-   rtw_write8(padapter, REG_TDECTRL+1, txpktbuf_bndy);
+   rtw_write8(padapter, REG_TDECTRL + 1, txpktbuf_bndy);
 }

 static void _InitNormalChipRegPriority(
@@ -569,7 +569,7 @@ static void HalRxAggr8723BSdio(struct adapter *padapter)
valueDMAPageCount = 0x06;
}

-   rtw_write8(padapter, REG_RXDMA_AGG_PG_TH+1, valueDMATimeout);
+   rtw_write8(padapter, REG_RXDMA_AGG_PG_TH + 1, valueDMATimeout);
rtw_write8(padapter, REG_RXDMA_AGG_PG_TH, valueDMAPageCount);
 }

@@ -588,8 +588,8 @@ static void sdio_AggSettingRxUpdate(struct adapter 
*padapter)
rtw_write8(padapter, REG_TRXDMA_CTRL, valueDMA);

valueRxAggCtrl |= RXDMA_AGG_MODE_EN;
-   valueRxAggCtrl |= ((aggBurstNum<<2) & 0x0C);
-   valueRxAggCtrl |= ((aggBurstSize<<4) & 0x30);
+   valueRxAggCtrl |= ((aggBurstNum << 2) & 0x0C);
+   valueRxAggCtrl |= ((aggBurstSize << 4) & 0x30);
rtw_write8(padapter, REG_RXDMA_MODE_CTRL_8723B, valueRxAggCtrl);/* 
RxAggLowThresh = 4*1K */
 }

@@ -754,11 +754,11 @@ static u32 rtl8723bs_hal_init(struct adapter *padapter)
rtw_hal_get_hwreg(padapter, HW_VAR_CPWM, _orig);

/* ser rpwm */
-   val8 = rtw_read8(padapter, SDIO_LOCAL_BASE|SDIO_REG_HRPWM1);
+   val8 = rtw_read8(padapter, SDIO_LOCAL_BASE | SDIO_REG_HRPWM1);
val8 &= 0x80;
val8 += 0x80;
val8 |= BIT(6);
-   rtw_write8(padapter, SDIO_LOCAL_BASE|SDIO_REG_HRPWM1, val8);
+   rtw_write8(padapter, SDIO_LOCAL_BASE | SDIO_REG_HRPWM1, val8);
DBG_871X("%s: write rpwm =%02x\n", __func__, val8);
 

[PATCH 1/2] staging: rtl8723bs: hal: sdio_halinit: fix comparison to true/false is error prone

[Hariprasad Kelam]

CHECK: Using comparison to false is error prone
CHECK: Using comparison to true is error prone

Signed-off-by: Hariprasad Kelam 
---
 drivers/staging/rtl8723bs/hal/sdio_halinit.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/rtl8723bs/hal/sdio_halinit.c 
b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
index 3c65a9c..70f9e1d 100644
--- a/drivers/staging/rtl8723bs/hal/sdio_halinit.c
+++ b/drivers/staging/rtl8723bs/hal/sdio_halinit.c
@@ -26,7 +26,7 @@ static u8 CardEnable(struct adapter *padapter)


rtw_hal_get_hwreg(padapter, HW_VAR_APFM_ON_MAC, );
-   if (bMacPwrCtrlOn == false) {
+   if (!bMacPwrCtrlOn) {
/*  RSV_CTRL 0x1C[7:0] = 0x00 */
/*  unlock ISO/CLK/Power control register */
rtw_write8(padapter, REG_RSV_CTRL, 0x0);
@@ -127,7 +127,7 @@ u8 _InitPowerOn_8723BS(struct adapter *padapter)

/*  only cmd52 can be used before power on(card enable) */
ret = CardEnable(padapter);
-   if (ret == false) {
+   if (!ret) {
RT_TRACE(
_module_hci_hal_init_c_,
_drv_emerg_,
@@ -838,7 +838,7 @@ static u32 rtl8723bs_hal_init(struct adapter *padapter)

 /* SIC_Init(padapter); */

-   if (pwrctrlpriv->reg_rfoff == true)
+   if (pwrctrlpriv->reg_rfoff)
pwrctrlpriv->rf_pwrstate = rf_off;

/*  2010/08/09 MH We need to check if we need to turnon or off RF after 
detecting */
@@ -1081,7 +1081,7 @@ static void CardDisableRTL8723BSdio(struct adapter 
*padapter)
ret = false;
rtw_hal_set_hwreg(padapter, HW_VAR_APFM_ON_MAC, );
ret = HalPwrSeqCmdParsing(padapter, PWR_CUT_ALL_MSK, PWR_FAB_ALL_MSK, 
PWR_INTF_SDIO_MSK, rtl8723B_card_disable_flow);
-   if (ret == false) {
+   if (!ret) {
DBG_8192C(KERN_ERR "%s: run CARD DISABLE flow fail!\n", 
__func__);
}
 }
@@ -1091,9 +1091,9 @@ static u32 rtl8723bs_hal_deinit(struct adapter *padapter)
struct dvobj_priv *psdpriv = padapter->dvobj;
struct debug_priv *pdbgpriv = >drv_dbg;

-   if (padapter->hw_init_completed == true) {
+   if (padapter->hw_init_completed) {
if (adapter_to_pwrctl(padapter)->bips_processing == true) {
-   if (padapter->netif_up == true) {
+   if (padapter->netif_up) {
int cnt = 0;
u8 val8 = 0;

@@ -1387,7 +1387,7 @@ static s32 _ReadAdapterInfo8723BS(struct adapter 
*padapter)
RT_TRACE(_module_hci_hal_init_c_, _drv_info_, 
("+_ReadAdapterInfo8723BS\n"));

/*  before access eFuse, make sure card enable has been called */
-   if (padapter->hw_init_completed == false)
+   if (!padapter->hw_init_completed)
_InitPowerOn_8723BS(padapter);


@@ -1404,7 +1404,7 @@ static s32 _ReadAdapterInfo8723BS(struct adapter 
*padapter)
_ReadPROMContent(padapter);
_InitOtherVariable(padapter);

-   if (padapter->hw_init_completed == false) {
+   if (!padapter->hw_init_completed) {
rtw_write8(padapter, 0x67, 0x00); /*  for BT, Switch Ant 
control to BT */
CardDisableRTL8723BSdio(padapter);/* for the power consumption 
issue,  wifi ko module is loaded during booting, but wifi GUI is off */
}
--
2.7.4

Re: [PATCH 1/2] PCI: altera: Fix configuration type based on secondary number

[Ley Foon Tan]

On Thu, May 30, 2019 at 11:25 PM Lorenzo Pieralisi
 wrote:
>
> On Fri, May 24, 2019 at 02:07:25PM +0800, Ley Foon Tan wrote:
> > This fix issue when access config from PCIe switch.
> >
> > Stratix 10 PCIe controller does not support Type 1 to Type 0 conversion
> > as previous version (V1) does.
> >
> > The PCIe controller need to send Type 0 config TLP if the targeting bus
> > matches with the secondary bus number, which is when the TLP is targeting
> > the immediate device on the link.
> >
> > The PCIe controller send Type 1 config TLP if the targeting bus is
> > larger than the secondary bus, which is when the TLP is targeting the
> > device not immediate on the link.
> >
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  drivers/pci/controller/pcie-altera.c | 22 --
> >  1 file changed, 20 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pci/controller/pcie-altera.c 
> > b/drivers/pci/controller/pcie-altera.c
> > index 27222071ace7..047bcc214f9b 100644
> > --- a/drivers/pci/controller/pcie-altera.c
> > +++ b/drivers/pci/controller/pcie-altera.c
> > @@ -44,6 +44,8 @@
> >  #define S10_RP_RXCPL_STATUS  0x200C
> >  #define S10_RP_CFG_ADDR(pcie, reg)   \
> >   (((pcie)->hip_base) + (reg) + (1 << 20))
> > +#define S10_RP_SECONDARY(pcie)   \
> > + readb(S10_RP_CFG_ADDR(pcie, PCI_SECONDARY_BUS))
> >
> >  /* TLP configuration type 0 and 1 */
> >  #define TLP_FMTTYPE_CFGRD0   0x04/* Configuration Read Type 0 
> > */
> > @@ -63,6 +65,14 @@
> >   bus == pcie->root_bus_nr) ? pcie->pcie_data->cfgwr0 \
> >   : pcie->pcie_data->cfgwr1) << 24) | \
> >   TLP_PAYLOAD_SIZE)
> > +#define S10_TLP_CFGRD_DW0(pcie, bus) \
> > + (bus) > S10_RP_SECONDARY(pcie)) ? pcie->pcie_data->cfgrd0   \
> > + : pcie->pcie_data->cfgrd1) << 24) | \
> > + TLP_PAYLOAD_SIZE)
> > +#define S10_TLP_CFGWR_DW0(pcie, bus) \
> > + (bus) > S10_RP_SECONDARY(pcie)) ? pcie->pcie_data->cfgwr0   \
> > + : pcie->pcie_data->cfgwr1) << 24) | \
> > + TLP_PAYLOAD_SIZE)
> >  #define TLP_CFG_DW1(pcie, tag, be)   \
> >   (((TLP_REQ_ID(pcie->root_bus_nr,  RP_DEVFN)) << 16) | (tag << 8) | 
> > (be))
> >  #define TLP_CFG_DW2(bus, devfn, offset)  \
> > @@ -327,7 +337,11 @@ static int tlp_cfg_dword_read(struct altera_pcie 
> > *pcie, u8 bus, u32 devfn,
> >  {
> >   u32 headers[TLP_HDR_SIZE];
> >
> > - headers[0] = TLP_CFGRD_DW0(pcie, bus);
> > + if (pcie->pcie_data->version == ALTERA_PCIE_V1)
> > + headers[0] = TLP_CFGRD_DW0(pcie, bus);
> > + else
> > + headers[0] = S10_TLP_CFGRD_DW0(pcie, bus);
> > +
> >   headers[1] = TLP_CFG_DW1(pcie, TLP_READ_TAG, byte_en);
> >   headers[2] = TLP_CFG_DW2(bus, devfn, where);
> >
> > @@ -342,7 +356,11 @@ static int tlp_cfg_dword_write(struct altera_pcie 
> > *pcie, u8 bus, u32 devfn,
> >   u32 headers[TLP_HDR_SIZE];
> >   int ret;
> >
> > - headers[0] = TLP_CFGWR_DW0(pcie, bus);
> > + if (pcie->pcie_data->version == ALTERA_PCIE_V1)
> > + headers[0] = TLP_CFGWR_DW0(pcie, bus);
> > + else
> > + headers[0] = S10_TLP_CFGWR_DW0(pcie, bus);
> > +
>
> Why don't you rewrite all these macros as an eg:
>
> static inline u32 get_tlp_header()
> {}
>
> where you can also handle the version and everything needed to
> detect what header should be set-up ?
>
Okay, will change this.

Thanks.

Regards
Ley Foon

Re: [PATCH v2 2/3] KVM: X86: Provide a capability to disable cstate msr read intercepts

[Wanpeng Li]

On Tue, 11 Jun 2019 at 19:09, Paolo Bonzini  wrote:
>
> On 11/06/19 09:38, Wanpeng Li wrote:
> > MSR_CORE_C1_RES is unreadable except for ATOM platform, so I think we
> > can avoid the complex logic to handle C1 now. :)
>
> I disagree.  Linux uses it on all platforms is available, and virtual
> machines that don't pass mwait through _only_ have C1, so it would be
> less useful to have deep C-state residency MSRs and not C1 residency.

Your design heavily depends on read host MSR_CORE_C1_RES for C1
residency msr emulation, however, the host MSR_CORE_C1_RES is
unreadable.
#rdmsr 0x660
rdmsr: CPU 0 cannot read MSR 0x0660

Refer to turbostat codes,
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/power/x86/turbostat/turbostat.c#n1335
C1 is derivated from other parameters. use_c1_residency_msr is true
just for ATOM platform.

Regards,
Wanpeng Li

Re: [RFC PATCH] Add script to add/remove/rename/renumber syscalls and resolve conflicts

[Linus Torvalds]

On Tue, Jun 11, 2019 at 3:27 AM David Howells  wrote:
>
> Add a script that simplifies the process of altering system call tables in
> the kernel sources.  It has five functions available:

Ugh, I hate it.

I'm sure the script is all kinds of clever and useful, but I really
think the solution is not this kind of helper script, but simply that
we should work at not having each architecture add new system calls
individually in the first place.

IOW, we should look at having just one unified table for new system
call numbers, and aim for the per-architecture ones to be for "legacy
numbering".

Maybe that won't happen, but in the _hope_ that it happens, I really
would prefer that people not work at making scripts for the current
nasty situation.

 Linus

Re: bcachefs status update (it's done cooking; let's get this sucker merged)

[Linus Torvalds]

On Mon, Jun 10, 2019 at 9:11 PM Dave Chinner  wrote:
>
> The same rwsem issues were seen on the mmap_sem, the shrinker rwsem,
> in a couple of device drivers, and so on. i.e. This isn't an XFS
> issue I'm raising here - I'm raising a concern about the lack of
> validation of core infrastructure and it's suitability for
> functionality extensions.

I haven't actually seen the reports.

That said, I do think this should be improving. The random
architecture-specific code is largely going away, and we'll have a
unified rwsem.

It might obviously cause some pain initially, but I think long-term we
should be much better off, at least avoiding the "on particular
configurations" issue..

  Linus

[PATCH] scsi: scsi_sysfs.c: Hide wwid sdev attr if VPD is not supported

[Marcos Paulo de Souza]

WWID composed from VPD data from device, specifically page 0x83. So,
when a device does not have VPD support, for example USB storage devices
where VPD is specifically disabled, a read into /device/wwid
file will always return ENXIO. To avoid this, change the
scsi_sdev_attr_is_visible function to hide wwid sysfs file when the
devices does not support VPD.

Signed-off-by: Marcos Paulo de Souza 
---
 drivers/scsi/scsi_sysfs.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index dbb206c90ecf..bfd890fa0c69 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1159,6 +1159,9 @@ static umode_t scsi_sdev_attr_is_visible(struct kobject 
*kobj,
struct device *dev = container_of(kobj, struct device, kobj);
struct scsi_device *sdev = to_scsi_device(dev);
 
+   /* do not present wwid if the device does not support VPD */
+   if (attr == _attr_wwid.attr && sdev->skip_vpd_pages)
+   return 0;
 
if (attr == _attr_queue_depth.attr &&
!sdev->host->hostt->change_queue_depth)
-- 
2.21.0

Re: [PATCH, RFC 2/2] Implement sharing/unsharing of PMDs for FS/DAX

[Kirill A. Shutemov]

On Fri, May 24, 2019 at 09:07:11AM -0700, Larry Bassel wrote:
> Again, I don't think this can happen in DAX. The only sharing allowed
> is for FS/DAX/2MiB pagesize.

Hm. I still don't follow. How do you guarantee that DAX actually allocated
continues space for the file on backing storage and you can map it with
PMD page? I believe you don't have such guarantee.


-- 
 Kirill A. Shutemov

[PATCH net-next v2 0/2] hinic: add rss support and rss paramters configuration

[Xue Chaojing]

This series add rss support for HINIC driver and implemente the ethtool
interface related to rss parameter configuration. user can use ethtool
configure rss parameters or show rss parameters.

Xue Chaojing (2):
  hinic: add rss support
  hinic: add support for rss parameters with ethtool

 drivers/net/ethernet/huawei/hinic/Makefile|   2 +-
 drivers/net/ethernet/huawei/hinic/hinic_dev.h |  28 +
 .../net/ethernet/huawei/hinic/hinic_ethtool.c | 508 ++
 .../net/ethernet/huawei/hinic/hinic_hw_dev.c  |  10 +-
 .../net/ethernet/huawei/hinic/hinic_hw_dev.h  |  36 ++
 .../net/ethernet/huawei/hinic/hinic_hw_wqe.h  |  16 +
 .../net/ethernet/huawei/hinic/hinic_main.c| 265 +
 .../net/ethernet/huawei/hinic/hinic_port.c| 379 +
 .../net/ethernet/huawei/hinic/hinic_port.h| 129 +
 9 files changed, 1231 insertions(+), 142 deletions(-)
 create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_ethtool.c

-- 
2.17.1

[PATCH net-next v2 2/2] hinic: add support for rss parameters with ethtool

[Xue Chaojing]

This patch adds support rss parameters with ethtool,
user can change hash key, hash indirection table, hash
function by ethtool -X, and show rss parameters by ethtool -x.

Signed-off-by: Xue Chaojing 
---
 drivers/net/ethernet/huawei/hinic/Makefile|   2 +-
 drivers/net/ethernet/huawei/hinic/hinic_dev.h |   2 +
 .../net/ethernet/huawei/hinic/hinic_ethtool.c | 508 ++
 .../net/ethernet/huawei/hinic/hinic_hw_dev.h  |  12 +-
 .../net/ethernet/huawei/hinic/hinic_main.c| 134 +
 .../net/ethernet/huawei/hinic/hinic_port.c| 126 +
 .../net/ethernet/huawei/hinic/hinic_port.h|  47 ++
 7 files changed, 696 insertions(+), 135 deletions(-)
 create mode 100644 drivers/net/ethernet/huawei/hinic/hinic_ethtool.c

diff --git a/drivers/net/ethernet/huawei/hinic/Makefile 
b/drivers/net/ethernet/huawei/hinic/Makefile
index 289ce88bb2d0..c592f1a0f54b 100644
--- a/drivers/net/ethernet/huawei/hinic/Makefile
+++ b/drivers/net/ethernet/huawei/hinic/Makefile
@@ -3,4 +3,4 @@ obj-$(CONFIG_HINIC) += hinic.o
 hinic-y := hinic_main.o hinic_tx.o hinic_rx.o hinic_port.o hinic_hw_dev.o \
   hinic_hw_io.o hinic_hw_qp.o hinic_hw_cmdq.o hinic_hw_wq.o \
   hinic_hw_mgmt.o hinic_hw_api_cmd.o hinic_hw_eqs.o hinic_hw_if.o \
-  hinic_common.o
+  hinic_common.o hinic_ethtool.o
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_dev.h 
b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
index 8926768280f2..5c9bc3319880 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
@@ -85,6 +85,8 @@ struct hinic_dev {
u16 num_rss;
u16 rss_limit;
struct hinic_rss_type   rss_type;
+   u8  *rss_hkey_user;
+   s32 *rss_indir_user;
 };
 
 #endif
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c 
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
new file mode 100644
index ..6a39b498fc1d
--- /dev/null
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -0,0 +1,508 @@
+// SPDX-License-Identifier: GPL-2.0
+/* Huawei HiNIC PCI Express Linux driver
+ * Copyright(c) 2017 Huawei Technologies Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+ * for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hinic_hw_qp.h"
+#include "hinic_hw_dev.h"
+#include "hinic_port.h"
+#include "hinic_tx.h"
+#include "hinic_rx.h"
+#include "hinic_dev.h"
+
+static void set_link_speed(struct ethtool_link_ksettings *link_ksettings,
+  enum hinic_speed speed)
+{
+   switch (speed) {
+   case HINIC_SPEED_10MB_LINK:
+   link_ksettings->base.speed = SPEED_10;
+   break;
+
+   case HINIC_SPEED_100MB_LINK:
+   link_ksettings->base.speed = SPEED_100;
+   break;
+
+   case HINIC_SPEED_1000MB_LINK:
+   link_ksettings->base.speed = SPEED_1000;
+   break;
+
+   case HINIC_SPEED_10GB_LINK:
+   link_ksettings->base.speed = SPEED_1;
+   break;
+
+   case HINIC_SPEED_25GB_LINK:
+   link_ksettings->base.speed = SPEED_25000;
+   break;
+
+   case HINIC_SPEED_40GB_LINK:
+   link_ksettings->base.speed = SPEED_4;
+   break;
+
+   case HINIC_SPEED_100GB_LINK:
+   link_ksettings->base.speed = SPEED_10;
+   break;
+
+   default:
+   link_ksettings->base.speed = SPEED_UNKNOWN;
+   break;
+   }
+}
+
+static int hinic_get_link_ksettings(struct net_device *netdev,
+   struct ethtool_link_ksettings
+   *link_ksettings)
+{
+   struct hinic_dev *nic_dev = netdev_priv(netdev);
+   enum hinic_port_link_state link_state;
+   struct hinic_port_cap port_cap;
+   int err;
+
+   ethtool_link_ksettings_zero_link_mode(link_ksettings, advertising);
+   ethtool_link_ksettings_add_link_mode(link_ksettings, supported,
+Autoneg);
+
+   link_ksettings->base.speed = SPEED_UNKNOWN;
+   link_ksettings->base.autoneg = AUTONEG_DISABLE;
+   link_ksettings->base.duplex = DUPLEX_UNKNOWN;
+
+   err = hinic_port_get_cap(nic_dev, _cap);
+   if (err) {
+   netif_err(nic_dev, drv, netdev,
+ 

[PATCH net-next v2 1/2] hinic: add rss support

[Xue Chaojing]

This patch adds rss support for the HINIC driver.

Signed-off-by: Xue Chaojing 
---
 drivers/net/ethernet/huawei/hinic/hinic_dev.h |  26 ++
 .../net/ethernet/huawei/hinic/hinic_hw_dev.c  |  10 +-
 .../net/ethernet/huawei/hinic/hinic_hw_dev.h  |  26 ++
 .../net/ethernet/huawei/hinic/hinic_hw_wqe.h  |  16 ++
 .../net/ethernet/huawei/hinic/hinic_main.c| 131 -
 .../net/ethernet/huawei/hinic/hinic_port.c| 253 ++
 .../net/ethernet/huawei/hinic/hinic_port.h|  82 ++
 7 files changed, 536 insertions(+), 8 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_dev.h 
b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
index 5186cc9023aa..8926768280f2 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_dev.h
@@ -31,6 +31,7 @@
 enum hinic_flags {
HINIC_LINK_UP = BIT(0),
HINIC_INTF_UP = BIT(1),
+   HINIC_RSS_ENABLE = BIT(2),
 };
 
 struct hinic_rx_mode_work {
@@ -38,6 +39,23 @@ struct hinic_rx_mode_work {
u32 rx_mode;
 };
 
+struct hinic_rss_type {
+   u8 tcp_ipv6_ext;
+   u8 ipv6_ext;
+   u8 tcp_ipv6;
+   u8 ipv6;
+   u8 tcp_ipv4;
+   u8 ipv4;
+   u8 udp_ipv6;
+   u8 udp_ipv4;
+};
+
+enum hinic_rss_hash_type {
+   HINIC_RSS_HASH_ENGINE_TYPE_XOR,
+   HINIC_RSS_HASH_ENGINE_TYPE_TOEP,
+   HINIC_RSS_HASH_ENGINE_TYPE_MAX,
+};
+
 struct hinic_dev {
struct net_device   *netdev;
struct hinic_hwdev  *hwdev;
@@ -45,6 +63,8 @@ struct hinic_dev {
u32 msg_enable;
unsigned inttx_weight;
unsigned intrx_weight;
+   u16 num_qps;
+   u16 max_qps;
 
unsigned intflags;
 
@@ -59,6 +79,12 @@ struct hinic_dev {
 
struct hinic_txq_stats  tx_stats;
struct hinic_rxq_stats  rx_stats;
+
+   u8  rss_tmpl_idx;
+   u8  rss_hash_engine;
+   u16 num_rss;
+   u16 rss_limit;
+   struct hinic_rss_type   rss_type;
 };
 
 #endif
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c 
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
index 756a7e3280bd..5e01672fd47b 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.c
@@ -98,9 +98,6 @@ static int get_capability(struct hinic_hwdev *hwdev,
if (nic_cap->num_qps > HINIC_Q_CTXT_MAX)
nic_cap->num_qps = HINIC_Q_CTXT_MAX;
 
-   /* num_qps must be power of 2 */
-   nic_cap->num_qps = BIT(fls(nic_cap->num_qps) - 1);
-
nic_cap->max_qps = dev_cap->max_sqs + 1;
if (nic_cap->max_qps != (dev_cap->max_rqs + 1))
return -EFAULT;
@@ -883,6 +880,13 @@ void hinic_free_hwdev(struct hinic_hwdev *hwdev)
hinic_free_hwif(hwdev->hwif);
 }
 
+int hinic_hwdev_max_num_qps(struct hinic_hwdev *hwdev)
+{
+   struct hinic_cap *nic_cap = >nic_cap;
+
+   return nic_cap->max_qps;
+}
+
 /**
  * hinic_hwdev_num_qps - return the number QPs available for use
  * @hwdev: the NIC HW device
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h 
b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
index fba4fe82472a..9c55374077f7 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
+++ b/drivers/net/ethernet/huawei/hinic/hinic_hw_dev.h
@@ -56,6 +56,14 @@ enum hinic_port_cmd {
 
HINIC_PORT_CMD_SET_PORT_STATE   = 41,
 
+   HINIC_PORT_CMD_SET_RSS_TEMPLATE_TBL = 43,
+
+   HINIC_PORT_CMD_SET_RSS_HASH_ENGINE  = 45,
+
+   HINIC_PORT_CMD_RSS_TEMP_MGR = 49,
+
+   HINIC_PORT_CMD_RSS_CFG  = 66,
+
HINIC_PORT_CMD_FWCTXT_INIT  = 69,
 
HINIC_PORT_CMD_SET_FUNC_STATE   = 93,
@@ -71,6 +79,22 @@ enum hinic_port_cmd {
HINIC_PORT_CMD_SET_LRO_TIMER= 244,
 };
 
+enum hinic_ucode_cmd {
+   HINIC_UCODE_CMD_MODIFY_QUEUE_CONTEXT= 0,
+   HINIC_UCODE_CMD_CLEAN_QUEUE_CONTEXT,
+   HINIC_UCODE_CMD_ARM_SQ,
+   HINIC_UCODE_CMD_ARM_RQ,
+   HINIC_UCODE_CMD_SET_RSS_INDIR_TABLE,
+   HINIC_UCODE_CMD_SET_RSS_CONTEXT_TABLE,
+   HINIC_UCODE_CMD_GET_RSS_INDIR_TABLE,
+   HINIC_UCODE_CMD_GET_RSS_CONTEXT_TABLE,
+   HINIC_UCODE_CMD_SET_IQ_ENABLE,
+   HINIC_UCODE_CMD_SET_RQ_FLUSH= 10
+};
+
+#define NIC_RSS_CMD_TEMP_ALLOC  0x01
+#define NIC_RSS_CMD_TEMP_FREE   0x02
+
 enum hinic_mgmt_msg_cmd {
HINIC_MGMT_MSG_CMD_BASE = 160,
 
@@ -230,6 +254,8 @@ struct hinic_hwdev *hinic_init_hwdev(struct pci_dev *pdev);
 
 void hinic_free_hwdev(struct hinic_hwdev *hwdev);
 
+int hinic_hwdev_max_num_qps(struct hinic_hwdev *hwdev);
+
 int hinic_hwdev_num_qps(struct hinic_hwdev *hwdev);
 
 struct hinic_sq *hinic_hwdev_get_sq(struct 

Re: [PATCH v3 2/2] power: supply: ucs1002: Add HWMON interface

[Andrey Smirnov]

On Tue, Jun 11, 2019 at 12:46 PM Sebastian Reichel  wrote:
>
> Hi,
>
> On Wed, Jun 05, 2019 at 11:39:45AM -0700, Guenter Roeck wrote:
> > On Wed, Jun 05, 2019 at 10:47:25AM -0700, Andrey Smirnov wrote:
> > > On Wed, Jun 5, 2019 at 9:26 AM Andrew F. Davis  wrote:
> > > >
> > > > On 6/5/19 3:23 AM, Andrey Smirnov wrote:
> > > > > Expose current sensors found on UCS1002 via HWMON.
> > > > >
> > > > > Signed-off-by: Andrey Smirnov 
> > > > > Reviewed-by: Guenter Roeck 
> > > > > Cc: Chris Healy 
> > > > > Cc: Cory Tusar 
> > > > > Cc: Lucas Stach 
> > > > > Cc: Fabio Estevam 
> > > > > Cc: Guenter Roeck 
> > > > > Cc: Sebastian Reichel 
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Cc: linux...@vger.kernel.org
> > > > > ---
> > > > >   drivers/power/supply/ucs1002_power.c | 6 ++
> > > > >   1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/drivers/power/supply/ucs1002_power.c 
> > > > > b/drivers/power/supply/ucs1002_power.c
> > > > > index 677f20a4d76f..a4b6b37549cf 100644
> > > > > --- a/drivers/power/supply/ucs1002_power.c
> > > > > +++ b/drivers/power/supply/ucs1002_power.c
> > > > > @@ -571,6 +571,12 @@ static int ucs1002_probe(struct i2c_client 
> > > > > *client,
> > > > >   return ret;
> > > > >   }
> > > > >
> > > > > + ret = devm_power_supply_add_hwmon_sysfs(info->charger);
> > > >
> > > > Could this be added to the core power supply framework on registering so
> > > > all devices get this, vs each driver having to add this line?
> > > >
> > >
> > > I'd say it is up to Sebastian to decide if this should be opt-out
> > > rather than opt-in. I have no objections to either approach.
> > >
> >
> > Same here, and agreed.
>
> I think this should be registered in power_supply_register() and
> free'd in power_supply_unregister(). It's not device specific at
> all and the functionality can be configured via Kconfig.
>

Sure, will do in v4.

Thanks,
Andrey Smirnov

linux-next 20190611: objtool warning

[Randy Dunlap]

Hi,

New warning AFAIK:

drivers/hwmon/smsc47m1.o: warning: objtool: fan_div_store()+0x11f: sibling call 
from callable instruction with modified stack frame


> gcc --version
gcc (SUSE Linux) 7.4.1 20190424 [gcc-7-branch revision 270538]


-- 
~Randy

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/11/19 5:46 PM, Aaro Koskinen wrote:

Hi,

On Tue, Jun 11, 2019 at 05:20:12PM -0500, Larry Finger wrote:

It is obvious that the case of a mask smaller than min_mask should be
handled by the IOMMU. In my system, CONFIG_IOMMU_SUPPORT is selected. All
other CONFIG variables containing IOMMU are not selected. When
dma_direct_supported() fails, should the system not try for an IOMMU
solution? Is the driver asking for the wrong type of memory? It is doing a
dma_and_set_mask_coherent() call.


I don't think we have IOMMU on G4. On G5 it should work (I remember fixing
b43 issue on G5, see 4c374af5fdee, unfortunately all my G5 Macs with b43
are dead and waiting for re-capping).


You are right. My configuration has CONFIG_IOMMU_SUPPORT=y, but there is no 
mention of an IOMMU in the log.


Larry

Re: [GIT PULL] (swiotlb) stable/for-linus-5.2

[pr-tracker-bot]

The pull request you sent on Tue, 11 Jun 2019 14:36:09 -0400:

> git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git 
> stable/for-linus-5.2

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/4d8f5f91b8a608980b173ef3382913c7405f82c3

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] VFIO fixes for v5.2-rc5

[pr-tracker-bot]

The pull request you sent on Tue, 11 Jun 2019 11:49:55 -0600:

> git://github.com/awilliam/linux-vfio.git tags/vfio-v5.2-rc5

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c23b07125f8aebf8b39fffa325145826098f7d8f

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

Re: [GIT PULL] Minor ptrace fixes for v5.2-rc5

[pr-tracker-bot]

The pull request you sent on Tue, 11 Jun 2019 15:23:27 -0500:

> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git 
> for-linus

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/aa7235483a838be79b7c22a86b0dc4cb12ee5dd6

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker

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

[Li, Aubrey]

On 2019/6/6 23:26, Julien Desfossez wrote:
> As mentioned above, we have come up with a fix for the long starvation
> of untagged interactive threads competing for the same core with tagged
> threads at the same priority. The idea is to detect the stall and boost
> the stalling threads priority so that it gets a chance next time.
> Boosting is done by a new counter(min_vruntime_boost) for every task
> which we subtract from vruntime before comparison. The new logic looks
> like this:
> 
> If we see that normalized runtimes are equal, we check the min_vruntimes
> of their runqueues and give a chance for the task in the runqueue with
> less min_vruntime. That will help it to progress its vruntime. While
> doing this, we boost the priority of the task in the sibling so that, we
> don’t starve the task in the sibling until the min_vruntime of this
> runqueue catches up.
> 
> If min_vruntimes are also equal, we do as before and consider the task
> ‘a’ of higher priority. Here we boost the task ‘b’ so that it gets to
> run next time.
> 
> The min_vruntime_boost is reset to zero once the task in on cpu. So only
> waiting tasks will have a non-zero value if it is starved while matching
> a task on the other sibling.
> 
> The attached patch has a sched_feature to enable the above feature so
> that you can compare the results with and without this feature.
> 
> What we observe with this patch is that it helps for untagged
> interactive tasks and fairness in general, but this increases the
> overhead of core scheduling when there is contention for the CPU with
> tasks of varying cpu usage. The general trend we see is that if there is
> a cpu intensive thread and multiple relatively idle threads in different
> tags, the cpu intensive tasks continuously yields to be fair to the
> relatively idle threads when it becomes runnable. And if the relatively
> idle threads make up for most of the tasks in a system and are tagged,
> the cpu intensive tasks sees a considerable drop in performance.
> 
> If you have any feedback or creative ideas to help improve, let us
> know !

The data on my side looks good with CORESCHED_STALL_FIX = true.

Environment setup
--
Skylake 8170 server, 2 numa nodes, 52 cores, 104 CPUs (HT on)
cgroup1 workload, sysbench (CPU mode, non AVX workload)
cgroup2 workload, gemmbench (AVX512 workload)

sysbench throughput result:
.--.
|NA/AVX vanilla-SMT [std% / sem%] cpu% |coresched-SMT   [std% / sem%]   
  +/- cpu% |  no-SMT [std% / sem%]   +/-  cpu% |
|--|
|  1/1490.8 [ 0.1%/ 0.0%] 1.9% |492.6   [ 0.1%/ 0.0%]   
  0.4%1.9% |   489.5 [ 0.1%/ 0.0%]  -0.3% 3.9% |
'--'
|  2/2975.0 [ 0.6%/ 0.1%] 3.9% |970.4   [ 0.4%/ 0.0%]   
 -0.5%3.9% |   975.6 [ 0.2%/ 0.0%]   0.1% 7.7% |
'--'
|  4/4   1856.9 [ 0.2%/ 0.0%] 7.8% |   1854.5   [ 0.3%/ 0.0%]   
 -0.1%7.8% |  1849.4 [ 0.8%/ 0.1%]  -0.4%14.8% |
'--'
|  8/8   3622.8 [ 0.2%/ 0.0%]14.6% |   3618.3   [ 0.1%/ 0.0%]   
 -0.1%   14.7% |  3626.6 [ 0.4%/ 0.0%]   0.1%30.1% |
'--'
| 16/16  6976.7 [ 0.2%/ 0.0%]30.1% |   6959.3   [ 0.3%/ 0.0%]   
 -0.2%   30.1% |  6964.4 [ 0.9%/ 0.1%]  -0.2%60.1% |
'--'
| 32/32 10347.7 [ 3.8%/ 0.4%]60.1% |  11525.4   [ 2.8%/ 0.3%]   
 11.4%   59.5% |  9810.5 [ 9.4%/ 0.8%]  -5.2%97.7% |
'--'
| 64/64 15284.9 [ 9.0%/ 0.9%]98.1% |  17022.1   [ 4.5%/ 0.5%]   
 11.4%   98.2% |  9989.7 [19.3%/ 1.1%] -34.6%   100.0% |
'--'
|128/12816211.3 [18.9%/ 1.9%]   100.0% |  16507.9   [ 6.1%/ 0.6%]   
  1.8%   99.8% | 10379.0 [12.6%/ 0.8%] -36.0%   100.0% |

Re: [BISECTED REGRESSION] b43legacy broken on G4 PowerBook

[Larry Finger]

On 6/11/19 5:46 PM, Benjamin Herrenschmidt wrote:

On Tue, 2019-06-11 at 17:20 -0500, Larry Finger wrote:

b43-pci-bridge 0001:11:00.0: dma_direct_supported: failed (mask =
0x3fff,
min_mask = 0x5000/0x5000, dma bits = 0x1f


Ugh ? A mask with holes in it ? That's very wrong... That min_mask is
bogus.


I agree, but that is not likely serious as most systems will have enough memory 
that the max_pfn term will be much larger than the initial min_mask, and 
min_mask will be unchanged by the min function. In addition, min_mask is not 
used beyond this routine, and then only to decide if direct dma is supported. 
The following patch generates masks with no holes, but I cannot see that it is 
needed.


diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 2c2772e9702a..e3edd4f29e80 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -384,7 +384,8 @@ int dma_direct_supported(struct device *dev, u64 mask)
else
min_mask = DMA_BIT_MASK(32);

-   min_mask = min_t(u64, min_mask, (max_pfn - 1) << PAGE_SHIFT);
+   min_mask = min_t(u64, min_mask, ((max_pfn - 1) << PAGE_SHIFT) |
+DMA_BIT_MASK(PAGE_SHIFT));

/*
 * This check needs to be against the actual bit mask value, so


Larry

Re: [PATCH] futex: Fix futex lock the wrong page

[zhangxiaoxu (A)]

This patch is for stable branch linux-4.4-y.

On 2019/6/12 9:54, ZhangXiaoxu wrote:

The upstram commit 65d8fc777f6d ("futex: Remove requirement
for lock_page() in get_futex_key()") use variable 'page' as
the page head, when merge it to stable branch, the variable
`page_head` is page head.

In the stable branch, the variable `page` not means the page
head, when lock the page head, we should lock 'page_head',
rather than 'page'.

It maybe lead a hung task problem.

Signed-off-by: ZhangXiaoxu 
Cc: sta...@vger.kernel.org
---
  kernel/futex.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index ec9df5b..15d850f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -593,8 +593,8 @@ again:
 * applies. If this is really a shmem page then the page lock
 * will prevent unexpected transitions.
 */
-   lock_page(page);
-   shmem_swizzled = PageSwapCache(page) || page->mapping;
+   lock_page(page_head);
+   shmem_swizzled = PageSwapCache(page_head) || page_head->mapping;
unlock_page(page_head);
put_page(page_head);
  

Re: [GIT PULL] Minor ptrace fixes for v5.2-rc5

[Linus Torvalds]

On Tue, Jun 11, 2019 at 10:23 AM Eric W. Biederman
 wrote:
>
> Apologies for being a little slow about getting this to you, I am still
> figuring out how to develop with a little baby in the house.

Heh. It gets better as they age. In just a couple of decades, you'll
find they have it all figured out..

  Linus

[PATCH] futex: Fix futex lock the wrong page

[ZhangXiaoxu]

The upstram commit 65d8fc777f6d ("futex: Remove requirement
for lock_page() in get_futex_key()") use variable 'page' as
the page head, when merge it to stable branch, the variable
`page_head` is page head.

In the stable branch, the variable `page` not means the page
head, when lock the page head, we should lock 'page_head',
rather than 'page'.

It maybe lead a hung task problem.

Signed-off-by: ZhangXiaoxu 
Cc: sta...@vger.kernel.org
---
 kernel/futex.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index ec9df5b..15d850f 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -593,8 +593,8 @@ again:
 * applies. If this is really a shmem page then the page lock
 * will prevent unexpected transitions.
 */
-   lock_page(page);
-   shmem_swizzled = PageSwapCache(page) || page->mapping;
+   lock_page(page_head);
+   shmem_swizzled = PageSwapCache(page_head) || page_head->mapping;
unlock_page(page_head);
put_page(page_head);
 
-- 
2.7.4

Re: [PATCH v3 2/4] KVM: LAPIC: lapic timer interrupt is injected by posted interrupt

[Wanpeng Li]

On Wed, 12 Jun 2019 at 04:39, Marcelo Tosatti  wrote:
>
> On Tue, Jun 11, 2019 at 08:17:07PM +0800, Wanpeng Li wrote:
> > From: Wanpeng Li 
> >
> > Dedicated instances are currently disturbed by unnecessary jitter due
> > to the emulated lapic timers fire on the same pCPUs which vCPUs resident.
> > There is no hardware virtual timer on Intel for guest like ARM. Both
> > programming timer in guest and the emulated timer fires incur vmexits.
> > This patch tries to avoid vmexit which is incurred by the emulated
> > timer fires in dedicated instance scenario.
> >
> > When nohz_full is enabled in dedicated instances scenario, the emulated
> > timers can be offload to the nearest busy housekeeping cpus since APICv
> > is really common in recent years. The guest timer interrupt is injected
> > by posted-interrupt which is delivered by housekeeping cpu once the emulated
> > timer fires.
> >
> > ~3% redis performance benefit can be observed on Skylake server.
> >
> > w/o patch:
> >
> > VM-EXIT  Samples  Samples%  Time%   Min Time  Max Time   Avg 
> > time
> >
> > EXTERNAL_INTERRUPT4291649.43%   39.30%   0.47us   106.09us   0.71us 
> > ( +-   1.09% )
> >
> > w/ patch:
> >
> > VM-EXIT  Samples  Samples%  Time%   Min Time  Max Time 
> > Avg time
> >
> > EXTERNAL_INTERRUPT6871 9.29% 2.96%   0.44us57.88us   0.72us 
> > ( +-   4.02% )
> >
> > Cc: Paolo Bonzini 
> > Cc: Radim Krčmář 
> > Signed-off-by: Wanpeng Li 
> > ---
> >  arch/x86/kvm/lapic.c | 32 +---
> >  1 file changed, 25 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
> > index e57eeba..020599f 100644
> > --- a/arch/x86/kvm/lapic.c
> > +++ b/arch/x86/kvm/lapic.c
> > @@ -133,6 +133,12 @@ inline bool 
> > posted_interrupt_inject_timer_enabled(struct kvm_vcpu *vcpu)
> >  }
> >  EXPORT_SYMBOL_GPL(posted_interrupt_inject_timer_enabled);
> >
> > +static inline bool can_posted_interrupt_inject_timer(struct kvm_vcpu *vcpu)
> > +{
> > + return posted_interrupt_inject_timer_enabled(vcpu) &&
> > + kvm_hlt_in_guest(vcpu->kvm);
> > +}
>
> Hi Li,

Hi Marcelo,

>
> Don't think its necessary to depend on kvm_hlt_in_guest: Can also use
> exitless injection if the guest is running (think DPDK style workloads
> that busy-spin on network card).
>

There are some discussions here.

https://lkml.org/lkml/2019/6/11/424
https://lkml.org/lkml/2019/6/5/436

Regards,
Wanpeng Li

Re: [PATCH v4] page cache: Store only head pages in i_pages

[Kirill A. Shutemov]

On Sun, Jun 02, 2019 at 10:47:35PM +0100, Chris Wilson wrote:
> Quoting Matthew Wilcox (2019-03-07 15:30:51)
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index 404acdcd0455..aaf88f85d492 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2456,6 +2456,9 @@ static void __split_huge_page(struct page *page, 
> > struct list_head *list,
> > if (IS_ENABLED(CONFIG_SHMEM) && 
> > PageSwapBacked(head))
> > shmem_uncharge(head->mapping->host, 1);
> > put_page(head + i);
> > +   } else if (!PageAnon(page)) {
> > +   __xa_store(>mapping->i_pages, head[i].index,
> > +   head + i, 0);
> 
> Forgiving the ignorant copy'n'paste, this is required:
> 
> +   } else if (PageSwapCache(page)) {
> +   swp_entry_t entry = { .val = page_private(head + i) };
> +   __xa_store(_address_space(entry)->i_pages,
> +  swp_offset(entry),
> +  head + i, 0);
> }
> }
>  
> The locking is definitely wrong.

Does it help with the problem, or it's just a possible lead?

-- 
 Kirill A. Shutemov

Re: [PATCH] arm64: configs: Enable GPIO_DAVINCI

[keerthy]

On 6/11/2019 11:49 PM, Tero Kristo wrote:

On 05/06/2019 09:14, Keerthy wrote:

Enable GPIO_DAVINCI and related configs for TI K3 AM6 platforms.

Signed-off-by: Keerthy 
---
  arch/arm64/configs/defconfig | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d1b72f99e2f4..57d7a4c207bd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -385,6 +385,9 @@ CONFIG_PINCTRL_QCS404=y
  CONFIG_PINCTRL_QDF2XXX=y
  CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
  CONFIG_PINCTRL_SDM845=y
+CONFIG_DEBUG_GPIO=y


Why DEBUG_GPIO?


Okay this can be left out.




+CONFIG_GPIO_SYSFS=y


Also, why GPIO_SYSFS?


This has been there for pretty much all the SoCs in the past
and one of the ways to validate GPIOs are functional. This is very much 
needed IMHO.




Both of the above are nice for debugging purposes, but should not be 
enabled by default imho, as they are not needed by drivers.



+CONFIG_GPIO_DAVINCI=y


I think you should not modify defconfig, rather add these as platform 
required features under arch/arm64/Kconfig.platforms?


I observed CONFIG_RESET_TI_SCI, CONFIG_TI_SCI_PROTOCOL which are 
platform specific in the defconfig and added them here. Already there 
are n number of GPIO config options as well under defconfig. If the norm 
is to add selects under arch/arm64/Kconfig.platforms then i am fine with 
that as well. Kindly let me know.


- Keerthy


-Tero


  CONFIG_GPIO_DWAPB=y
  CONFIG_GPIO_MB86S7X=y
  CONFIG_GPIO_PL061=y



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

Re: [PATCH v3 0/3] KVM: Yield to IPI target if necessary

[Nadav Amit]

> On Jun 11, 2019, at 6:18 PM, Wanpeng Li  wrote:
> 
> On Wed, 12 Jun 2019 at 00:57, Nadav Amit  wrote:
>>> On Jun 11, 2019, at 3:02 AM, Wanpeng Li  wrote:
>>> 
>>> On Tue, 11 Jun 2019 at 09:48, Nadav Amit  wrote:
> On Jun 10, 2019, at 6:45 PM, Wanpeng Li  wrote:
> 
> On Tue, 11 Jun 2019 at 09:11, Sean Christopherson
>  wrote:
>> On Mon, Jun 10, 2019 at 04:34:20PM +0200, Radim Krčmář wrote:
>>> 2019-05-30 09:05+0800, Wanpeng Li:
 The idea is from Xen, when sending a call-function IPI-many to vCPUs,
 yield if any of the IPI target vCPUs was preempted. 17% performance
 increasement of ebizzy benchmark can be observed in an over-subscribe
 environment. (w/ kvm-pv-tlb disabled, testing TLB flush call-function
 IPI-many since call-function is not easy to be trigged by userspace
 workload).
>>> 
>>> Have you checked if we could gain performance by having the yield as an
>>> extension to our PV IPI call?
>>> 
>>> It would allow us to skip the VM entry/exit overhead on the caller.
>>> (The benefit of that might be negligible and it also poses a
>>> complication when splitting the target mask into several PV IPI
>>> hypercalls.)
>> 
>> Tangetially related to splitting PV IPI hypercalls, are there any major
>> hurdles to supporting shorthand?  Not having to generate the mask for
>> ->send_IPI_allbutself and ->kvm_send_ipi_all seems like an easy to way
>> shave cycles for affected flows.
> 
> Not sure why shorthand is not used for native x2apic mode.
 
 Why do you say so? native_send_call_func_ipi() checks if allbutself
 shorthand should be used and does so (even though the check can be more
 efficient - I’m looking at that code right now…)
>>> 
>>> Please continue to follow the apic/x2apic driver. Just apic_flat set
>>> APIC_DEST_ALLBUT/APIC_DEST_ALLINC to ICR.
>> 
>> Indeed - I was sure by the name that it does it correctly. That’s stupid.
>> 
>> I’ll add it to the patch-set I am working on (TLB shootdown improvements),
>> if you don’t mind.
> 
> Original for hotplug cpu safe.
> https://lwn.net/Articles/138365/
> https://lwn.net/Articles/138368/
> Not sure shortcut native support is acceptable, I will play my
> kvm_send_ipi_allbutself and kvm_send_ipi_all. :)

Yes, I saw these threads before. But I think the test in
native_send_call_func_ipi() should take care of it.

I’ll recheck.

[PATCH v4] kernel/module: Fix mem leak in module_add_modinfo_attrs

[YueHaibing]

In module_add_modinfo_attrs if sysfs_create_file
fails, we forget to free allocated modinfo_attrs
and roll back the sysfs files.

Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting")
Signed-off-by: YueHaibing 
---
v4: call module_remove_modinfo_attrs only while i > 0
v3: reuse module_remove_modinfo_attrs
v2: free from '--i' instead of 'i--'
---
 kernel/module.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/kernel/module.c b/kernel/module.c
index f954d72..3310a39 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1696,6 +1696,8 @@ static int add_usage_links(struct module *mod)
return ret;
 }
 
+static void module_remove_modinfo_attrs(struct module *mod, int end);
+
 static int module_add_modinfo_attrs(struct module *mod)
 {
struct module_attribute *attr;
@@ -1710,24 +1712,34 @@ static int module_add_modinfo_attrs(struct module *mod)
return -ENOMEM;
 
temp_attr = mod->modinfo_attrs;
-   for (i = 0; (attr = modinfo_attrs[i]) && !error; i++) {
+   for (i = 0; (attr = modinfo_attrs[i]); i++) {
if (!attr->test || attr->test(mod)) {
memcpy(temp_attr, attr, sizeof(*temp_attr));
sysfs_attr_init(_attr->attr);
error = sysfs_create_file(>mkobj.kobj,
_attr->attr);
+   if (error)
+   goto error_out;
++temp_attr;
}
}
+
+   return 0;
+
+error_out:
+   if (i > 0)
+   module_remove_modinfo_attrs(mod, --i);
return error;
 }
 
-static void module_remove_modinfo_attrs(struct module *mod)
+static void module_remove_modinfo_attrs(struct module *mod, int end)
 {
struct module_attribute *attr;
int i;
 
for (i = 0; (attr = >modinfo_attrs[i]); i++) {
+   if (end >= 0 && i > end)
+   break;
/* pick a field to test for end of list */
if (!attr->attr.name)
break;
@@ -1815,7 +1827,7 @@ static int mod_sysfs_setup(struct module *mod,
return 0;
 
 out_unreg_modinfo_attrs:
-   module_remove_modinfo_attrs(mod);
+   module_remove_modinfo_attrs(mod, -1);
 out_unreg_param:
module_param_sysfs_remove(mod);
 out_unreg_holders:
@@ -1851,7 +1863,7 @@ static void mod_sysfs_fini(struct module *mod)
 {
 }
 
-static void module_remove_modinfo_attrs(struct module *mod)
+static void module_remove_modinfo_attrs(struct module *mod, int end)
 {
 }
 
@@ -1867,7 +1879,7 @@ static void init_param_lock(struct module *mod)
 static void mod_sysfs_teardown(struct module *mod)
 {
del_usage_links(mod);
-   module_remove_modinfo_attrs(mod);
+   module_remove_modinfo_attrs(mod, -1);
module_param_sysfs_remove(mod);
kobject_put(mod->mkobj.drivers_dir);
kobject_put(mod->holders_dir);
-- 
2.7.4

Re: [PATCH 16/16] mm: pass get_user_pages_fast iterator arguments in a structure

[Nadav Amit]

> On Jun 11, 2019, at 5:52 PM, Nicholas Piggin  wrote:
> 
> Christoph Hellwig's on June 12, 2019 12:41 am:
>> Instead of passing a set of always repeated arguments down the
>> get_user_pages_fast iterators, create a struct gup_args to hold them and
>> pass that by reference.  This leads to an over 100 byte .text size
>> reduction for x86-64.
> 
> What does this do for performance? I've found this pattern can be
> bad for store aliasing detection.

Note that sometimes such an optimization can also have adverse effect due to
stack protector code that gcc emits when you use such structs.

Matthew Wilcox encountered such a case:
https://patchwork.kernel.org/patch/10702741/

Re: [PATCH v3 0/3] KVM: Yield to IPI target if necessary

[Wanpeng Li]

On Wed, 12 Jun 2019 at 00:57, Nadav Amit  wrote:
>
> > On Jun 11, 2019, at 3:02 AM, Wanpeng Li  wrote:
> >
> > On Tue, 11 Jun 2019 at 09:48, Nadav Amit  wrote:
> >>> On Jun 10, 2019, at 6:45 PM, Wanpeng Li  wrote:
> >>>
> >>> On Tue, 11 Jun 2019 at 09:11, Sean Christopherson
> >>>  wrote:
>  On Mon, Jun 10, 2019 at 04:34:20PM +0200, Radim Krčmář wrote:
> > 2019-05-30 09:05+0800, Wanpeng Li:
> >> The idea is from Xen, when sending a call-function IPI-many to vCPUs,
> >> yield if any of the IPI target vCPUs was preempted. 17% performance
> >> increasement of ebizzy benchmark can be observed in an over-subscribe
> >> environment. (w/ kvm-pv-tlb disabled, testing TLB flush call-function
> >> IPI-many since call-function is not easy to be trigged by userspace
> >> workload).
> >
> > Have you checked if we could gain performance by having the yield as an
> > extension to our PV IPI call?
> >
> > It would allow us to skip the VM entry/exit overhead on the caller.
> > (The benefit of that might be negligible and it also poses a
> > complication when splitting the target mask into several PV IPI
> > hypercalls.)
> 
>  Tangetially related to splitting PV IPI hypercalls, are there any major
>  hurdles to supporting shorthand?  Not having to generate the mask for
>  ->send_IPI_allbutself and ->kvm_send_ipi_all seems like an easy to way
>  shave cycles for affected flows.
> >>>
> >>> Not sure why shorthand is not used for native x2apic mode.
> >>
> >> Why do you say so? native_send_call_func_ipi() checks if allbutself
> >> shorthand should be used and does so (even though the check can be more
> >> efficient - I’m looking at that code right now…)
> >
> > Please continue to follow the apic/x2apic driver. Just apic_flat set
> > APIC_DEST_ALLBUT/APIC_DEST_ALLINC to ICR.
>
> Indeed - I was sure by the name that it does it correctly. That’s stupid.
>
> I’ll add it to the patch-set I am working on (TLB shootdown improvements),
> if you don’t mind.

Original for hotplug cpu safe.
https://lwn.net/Articles/138365/
https://lwn.net/Articles/138368/
Not sure shortcut native support is acceptable, I will play my
kvm_send_ipi_allbutself and kvm_send_ipi_all. :)

Regards,
Wanpeng Li