Re: [PATCH v6 7/7] perf diff: Support hot streams comparison

[Jin, Yao]

Hi Arnaldo,

On 9/18/2020 4:26 AM, Arnaldo Carvalho de Melo wrote:

Em Fri, Sep 11, 2020 at 04:03:53PM +0800, Jin Yao escreveu:

This patch enables perf-diff with "--stream" option.

"--stream": Enable hot streams comparison

Now let's see examples.

perf record -b ...  Generate perf.data.old with branch data
perf record -b ...  Generate perf.data with branch data
perf diff --stream

[ Matched hot streams ]

hot chain pair 1:
 cycles: 1, hits: 27.77%  cycles: 1, hits: 9.24%
 ---  --
   main div.c:39   main div.c:39
   main div.c:44   main div.c:44

hot chain pair 2:
cycles: 34, hits: 20.06%cycles: 27, hits: 16.98%
 ---  --
   __random_r random_r.c:360   __random_r random_r.c:360


Would it be interesting to get the associated source code and show right below
these file:number lines?

- Arnaldo



Yes, that would be better. Let me think about the implementation.

Thanks
Jin Yao

Re: [PATCH v2] dt-bindings: mfd: rohm,bd71837-pmic: Add common properties

[Krzysztof Kozlowski]

On Fri, 18 Sep 2020 at 07:48, Vaittinen, Matti
 wrote:
>
> Hi d Ho peeps!
>
> On Thu, 2020-09-17 at 21:37 +0200, Krzysztof Kozlowski wrote:
> > Add common properties appearing in DTSes (clock-names,
> > clock-output-names) with the common values (actually used in DTSes)
> > to
> > fix dtbs_check warnings like:
> >
> >   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> > pmic@4b: 'clock-names', 'clock-output-names', do not match any of
> > the regexes: 'pinctrl-[0-9]+'
> >
> > Signed-off-by: Krzysztof Kozlowski 
> >
> > ---
> >
> > Changes since v1:
> > 1. Define the names, as used in existing DTS files.
> > ---
> >  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6
> > ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> > pmic.yaml
> > index 65018a019e1d..3bfdd33702ad 100644
> > --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> > @@ -32,9 +32,15 @@ properties:
> >clocks:
> >  maxItems: 1
> >
> > +  clock-names:
> > +const: osc
>
> I guess existing board dtses use "osc" then? Ok.

Yes.

>
> >"#clock-cells":
> >  const: 0
> >
> > +  clock-output-names:
> > +const: pmic_clk
>
> This is not a strong opinion but I feel that pmic_clk is a bit too
> generic name? I mean, what if there is a system with more than one
> PMICs? (I don't see such use-case with the BD718x7 though - but perhaps
> this can serve as a misleading example for other PMICs?

I don't expect two PMICs. Sometimes secondary device is added with few
regulators, e.g. a MUIC. Still only one device can supply the CPU and
probably this would be called PMIC.

> For example
> with the ROHM BD96801 family there may be multiple PMICs in one
> system). Anyways - if Rob is happy with this then please go with it :)

The name was taken from existing DTS files. That was Rob's idea as well.

Best regards,
Krzysztof

>
> Acked-By: Matti Vaittinen 
>  *
> Thanks again for improving these bindings! I am constantly struggling
> with these x_x. Writing the bindings is probably hardest part of PMIC
> driver development -_-;
>
>

Re: [PATCH v13 2/2] mtd: rawnand: Add NAND controller support on Intel LGM SoC

[Ramuthevar, Vadivel MuruganX]

Hi Andy,

 Thank you for the review comments...

On 17/9/2020 9:05 pm, Andy Shevchenko wrote:

On Thu, Sep 17, 2020 at 08:33:08AM +0800, Ramuthevar,Vadivel MuruganX wrote:

From: Ramuthevar Vadivel Murugan 

This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.

DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported. Data register used to support the read/write
operation from/to device.

NAND controller driver implements ->exec_op() to replace legacy hooks,
these specific call-back method to execute NAND operations.


...


+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 



+#include 
+#include 


io.h is guaranteed to be included by iopoll.h.

Noted



+#include 
+#include 
+#include 



+#include 
+#include 
+#include 
+#include 


Since mtd is a hosting framework for this driver, I would move this group of 
headers after more generic ones with a blank line in between.

okay, noted




+#include 


And this I think is guaranteed to be included by io.h.

Sure, will check and update.



+#include 
+#include 
+#include 



+#include 


Dup? It's exactly the reason how alphabetical order can help.

Good catch


...


+#define EBU_ADDR_SEL(n)(0x20 + (n) * 4)


I think 0x20 is an offset here, and better to have it as 0x020 to be consistent
with all other offsets.

...


+#define EBU_BUSCON(n)  (0x60 + (n) * 4)


Ditto.

Noted, will update


...


+static void ebu_nand_setup_timing(struct ebu_nand_controller *ctrl,
+ const struct nand_sdr_timings *timings)
+{
+   unsigned int rate = clk_get_rate(ctrl->clk) / 100;


HZ_PER_MHZ?

yes, you're right we can use it.



+   unsigned int period = DIV_ROUND_UP(100, rate);


USEC_PER_SEC?

yes, you're right we can use it.



+   u32 trecov, thold, twrwait, trdwait;
+   u32 reg = 0;
+
+   trecov = DIV_ROUND_UP(max(timings->tREA_max, timings->tREH_min),
+ period);
+   reg |= EBU_BUSCON_RECOVC(trecov);
+
+   thold = DIV_ROUND_UP(max(timings->tDH_min, timings->tDS_min), period);
+   reg |= EBU_BUSCON_HOLDC(thold);
+
+   trdwait = DIV_ROUND_UP(max(timings->tRC_min, timings->tREH_min),
+  period);
+   reg |= EBU_BUSCON_WAITRDC(trdwait);
+
+   twrwait = DIV_ROUND_UP(max(timings->tWC_min, timings->tWH_min), period);
+   reg |= EBU_BUSCON_WAITWRC(twrwait);
+
+   reg |= EBU_BUSCON_CMULT_V4 | EBU_BUSCON_BCGEN_CS | EBU_BUSCON_ALEC |
+   EBU_BUSCON_SETUP_EN;
+
+   writel(reg, ctrl->ebu + EBU_BUSCON(ctrl->cs_num));
+}


...


+   if (oob_required) {
+   reg = (chip->oob_poi[3] << 24) | (chip->oob_poi[2] << 16) |
+   (chip->oob_poi[1] << 8) | chip->oob_poi[0];


get_unligned_le32()?

last time seen system crash ,so I left it.


...


+   reg = (chip->oob_poi[7] << 24) | (chip->oob_poi[6] << 16) |
+   (chip->oob_poi[5] << 8) | chip->oob_poi[4];


Ditto.

Let me double check will add it, keep the same if not


...


+   ret = readl_poll_timeout_atomic(int_sta, val,
+   !(val & HSNAND_INT_STA_WR_C), 10, 1000);


Slightly better (logically split between lines):

ret = readl_poll_timeout_atomic(int_sta, val, !(val & 
HSNAND_INT_STA_WR_C),
10, 1000);

Thanks!, will update




+   if (ret)
+   return ret;


...


+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "ebunand");
+   ebu_host->ebu = devm_ioremap_resource(&pdev->dev, res);


Why not to use

ebu_host->ebu = devm_platform_ioremap_resource_byname(&pdev->dev, 
"ebunand");

As Boris mtd-maintainer suggested me to split into 2 API's, thanks!.


?


+   if (IS_ERR(ebu_host->ebu))
+   return PTR_ERR(ebu_host->ebu);
+
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "hsnand");
+   ebu_host->hsnand = devm_ioremap_resource(&pdev->dev, res);


Ditto.


+   if (IS_ERR(ebu_host->hsnand))
+   return PTR_ERR(ebu_host->hsnand);


...



+   for (i = 0; i < MAX_CS; i++) {
+   resname = devm_kasprintf(dev, GFP_KERNEL, "nand_cs%d", i);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
+  resname);



+   if (!res)
+   return -EINVAL;


Redundant check.


+   ebu_host->cs[i].chipaddr = devm_ioremap_resource(dev, res);


Ditto (see above).

Noted



+   ebu_host->cs[i].nand_pa = res->start;
+   if (IS_ERR(ebu_host->cs[i].chipaddr))
+   return PTR_ERR(ebu_host->cs[i].chipaddr);
+   }


...


+   ebu_host->clk = devm_clk_get(dev, NULL);
+   if (IS_ERR(ebu_host->

RE: [PATCH] net: phy: realtek: fix rtl8211e rx/tx delay config

[劉偉權]

Hi Serge,
Thanks for your reply. There is a confidential issue that realtek doesn't offer 
the detail of a full register layout for configuration register. 

The default setting for this configuration register should be 0x8148. 
Basically, no need to change it. If you need to enable RGMII RX Delay or RGMII 
TX Delay via register setting, you also need to enable Force Tx RX Delay 
controlled as well.
13 = force Tx RX Delay controlled by bit12 bit11
12 = Tx Delay
11 = Rx Delay 

Current code in U-boot could change the register value from 0x8148 to 0xb548 
(0x8148|0xb400). Bit12 and Bit13 are set, and  RGMII TX delay enabled.
https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/realtek.c

I hope this information could help a bit.
B.R.
Willy

-Original Message-
From: Serge Semin  
Sent: Thursday, September 17, 2020 6:11 PM
To: 劉偉權 
Cc: and...@lunn.ch; hkallwe...@gmail.com; li...@armlinux.org.uk; 
da...@davemloft.net; k...@kernel.org; net...@vger.kernel.org; 
linux-kernel@vger.kernel.org; Ryan Kao ; Kyle Evans 
; Joe Hershberger ; Peter Robinson 

Subject: Re: [PATCH] net: phy: realtek: fix rtl8211e rx/tx delay config

Hello Willy,
Thanks for the patch. My comments are below.

I've Cc'ed the U-boot/FreeBSD, who might be also interested in the solution 
you've provided.

On Thu, Sep 17, 2020 at 09:47:33AM +0800, Willy Liu wrote:
> RGMII RX Delay and TX Delay settings will not applied if Force TX RX 
> Delay Control bit is not set.
> Register bit for configuration pins:
> 13 = force Tx RX Delay controlled by bit12 bit11
> 12 = Tx Delay
> 11 = Rx Delay

This is a very useful information, but it contradicts a bit to what knowledge 
we've currently got about that magical register. Current code in U-boot does 
the delays configuration by means of another bits:
https://elixir.bootlin.com/u-boot/v2020.10-rc4/source/drivers/net/phy/realtek.c

Could you provide a full register layout, so we'd know for sure what that 
register really does and finally close the question for good?

> 
> Fixes: f81dadbcf7fd ("net: phy: realtek: Add rtl8211e rx/tx delays 
> config")
> Signed-off-by: Willy Liu 
> ---
>  drivers/net/phy/realtek.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)  mode change 100644 
> => 100755 drivers/net/phy/realtek.c
> 
> diff --git a/drivers/net/phy/realtek.c b/drivers/net/phy/realtek.c old 
> mode 100644 new mode 100755 index 95dbe5e..3fddd57
> --- a/drivers/net/phy/realtek.c
> +++ b/drivers/net/phy/realtek.c
> @@ -32,9 +32,9 @@
>  #define RTL8211F_TX_DELAYBIT(8)
>  #define RTL8211F_RX_DELAYBIT(3)
>  

> -#define RTL8211E_TX_DELAYBIT(1)
> -#define RTL8211E_RX_DELAYBIT(2)
> -#define RTL8211E_MODE_MII_GMII   BIT(3)
> +#define RTL8211E_CTRL_DELAY  BIT(13)
> +#define RTL8211E_TX_DELAYBIT(12)
> +#define RTL8211E_RX_DELAYBIT(11)

So, what do BIT(1) and BIT(2) control then? Could you explain?

>  
>  #define RTL8201F_ISR 0x1e
>  #define RTL8201F_IER 0x13
> @@ -249,13 +249,13 @@ static int rtl8211e_config_init(struct phy_device 
> *phydev)
>   val = 0;
>   break;
>   case PHY_INTERFACE_MODE_RGMII_ID:
> - val = RTL8211E_TX_DELAY | RTL8211E_RX_DELAY;
> + val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY | 
> RTL8211E_RX_DELAY;
>   break;
>   case PHY_INTERFACE_MODE_RGMII_RXID:
> - val = RTL8211E_RX_DELAY;
> + val = RTL8211E_CTRL_DELAY | RTL8211E_RX_DELAY;
>   break;
>   case PHY_INTERFACE_MODE_RGMII_TXID:
> - val = RTL8211E_TX_DELAY;
> + val = RTL8211E_CTRL_DELAY | RTL8211E_TX_DELAY;
>   break;
>   default: /* the rest of the modes imply leaving delays as is. */
>   return 0;
> @@ -265,9 +265,8 @@ static int rtl8211e_config_init(struct phy_device *phydev)
>* 0xa4 extension page (0x7) layout. It can be used to disable/enable
>* the RX/TX delays otherwise controlled by RXDLY/TXDLY pins. It can
>* also be used to customize the whole configuration register:

> -  * 8:6 = PHY Address, 5:4 = Auto-Negotiation, 3 = Interface Mode Select,
> -  * 2 = RX Delay, 1 = TX Delay, 0 = SELRGV (see original PHY datasheet
> -  * for details).
> +  * 13 = Force Tx RX Delay controlled by bit12 bit11,
> +  * 12 = RX Delay, 11 = TX Delay

Here you've removed the register layout description and replaced it with just 
three bits info. So from now the text above doesn't really corresponds to what 
follows.

I might have forgotten something, but AFAIR that register bits state mapped 
well to what was available on the corresponding external pins. So if you've got 
a sacred knowledge what configs are really hidden behind that register, please 
open it up. This in-code comment would be a g

Re: [PATCH v6 0/7] perf: Stream comparison

[Jin, Yao]

Hi Arnaldo,

On 9/18/2020 4:13 AM, Arnaldo Carvalho de Melo wrote:

Em Thu, Sep 17, 2020 at 03:05:56PM +0200, Jiri Olsa escreveu:

On Fri, Sep 11, 2020 at 04:03:46PM +0800, Jin Yao wrote:

SNIP


   main div.c:40
   main div.c:40
   main div.c:39

[ Hot streams in new perf data only ]

hot chain 1:
  cycles: 4, hits: 4.54%
  --
   main div.c:42
   compute_flag div.c:28

hot chain 2:
  cycles: 5, hits: 3.51%
  --
   main div.c:39
   main div.c:44
   main div.c:42
   compute_flag div.c:28

  v6:
  ---
  Rebase to perf/core


it looks good to me

Acked-by: Jiri Olsa 


Jin,

I'm sorry I only got to look at this now, there are some issues,
I'll try to point them out patch by patch,

Thanks,

- Arnaldo



Thanks so much for looking at this patchset! :)

I will fix the issues which you point out in other mail threads. Once the fixes are done, I will 
post v7.


Thanks
Jin Yao

Re: [PATCH AUTOSEL 5.4 041/330] USB: serial: mos7840: fix probe error handling

[Johan Hovold]

On Thu, Sep 17, 2020 at 09:56:21PM -0400, Sasha Levin wrote:
> From: Johan Hovold 
> 
> [ Upstream commit 960fbd1ca584a5b4cd818255769769d42bfc6dbe ]
> 
> The driver would return success and leave the port structures
> half-initialised if any of the register accesses during probe fails.
> 
> This would specifically leave the port control urb unallocated,
> something which could trigger a NULL pointer dereference on interrupt
> events.
> 
> Fortunately the interrupt implementation is completely broken and has
> never even been enabled...
> 
> Note that the zero-length-enable register write used to set the zle-flag
> for all ports is moved to attach.
> 
> Reviewed-by: Greg Kroah-Hartman 
> Signed-off-by: Johan Hovold 
> Signed-off-by: Sasha Levin 

Please drop this from all stable queues. As the commit message and
missing stable-cc tag suggests, it's not needed.

Sasha, please stop sending AUTOSEL patches for usb-serial. I think this
the fourth time I ask you now.

Johan

Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions

[Dan Scally]

Good morning

On 18/09/2020 07:22, Sakari Ailus wrote:
> Hi Dan,
>
> On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
>> Hi Sakari - thanks for the comments
>>
>> On 16/09/2020 10:17, Sakari Ailus wrote:
>>> Moi Daniel and Heikki,
>>>
>>> On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
 From: Heikki Krogerus 

 This implements the remaining .graph_* callbacks in the
 fwnode operations vector for the software nodes. That makes
 the fwnode_graph*() functions available in the drivers also
 when software nodes are used.

 The implementation tries to mimic the "OF graph" as much as
 possible, but there is no support for the "reg" device
 property. The ports will need to have the index in their
 name which starts with "port" (for example "port0", "port1",
 ...) and endpoints will use the index of the software node
 that is given to them during creation. The port nodes can
 also be grouped under a specially named "ports" subnode,
 just like in DT, if necessary.

 The remote-endpoints are reference properties under the
 endpoint nodes that are named "remote-endpoint". 

 Signed-off-by: Heikki Krogerus 
 Co-developed-by: Daniel Scally 
 Signed-off-by: Daniel Scally 
 ---
 changes in v2:
- added software_node_device_is_available
- altered software_node_get_next_child to get references
- altered software_node_get_next_endpoint to release references
to ports and avoid passing invalid combinations of swnodes to
software_node_get_next_child
- altered swnode_graph_find_next_port to release port rather than
old

  drivers/base/swnode.c | 129 +-
  1 file changed, 127 insertions(+), 2 deletions(-)

 diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
 index 010828fc785b..d69034b807e3 100644
 --- a/drivers/base/swnode.c
 +++ b/drivers/base/swnode.c
 @@ -363,6 +363,11 @@ static void software_node_put(struct fwnode_handle 
 *fwnode)
kobject_put(&swnode->kobj);
  }
  
 +static bool software_node_device_is_available(const struct fwnode_handle 
 *fwnode)
 +{
 +  return is_software_node(fwnode);
>>> This basically tells whether the device is there. Are there software node
>>> based devices, i.e. do you need this?
>>>
>>> If you do really need this, then I guess this could just return true for
>>> now as if you somehow get here, the node is a software node anyway.
>> I do think its better to include it; I'm targeting using this with
>> ipu3-cio2; the cio2_parse_firmware() call there doesn't pass
>> FWNODE_GRAPH_DEVICE_DISABLED to fwnode_graph_get_endpoint_by_id() so
> I wonder if this has something to do with replacing the device's fwnode
> in the cio2-bridge patch.
>
> It's the device that needs to be enabled, and it's not a software node.
>
I think it is because of that yes, but I don't see a way around it at
the moment - unless there's a way to attach the software_node port and
endpoints that cio2-bridge creates to the device's existing firmware
instead.

Re: [PATCH v6 5/8] crypto: testmgr - support test with different ciphertext per encryption

[Herbert Xu]

On Thu, Sep 03, 2020 at 09:12:39PM +0800, Tianjia Zhang wrote:
> Some asymmetric algorithms will get different ciphertext after
> each encryption, such as SM2, and let testmgr support the testing
> of such algorithms.
> 
> In struct akcipher_testvec, set c and c_size to be empty, skip
> the comparison of the ciphertext, and compare the decrypted
> plaintext with m to achieve the test purpose.
> 
> Signed-off-by: Tianjia Zhang 
> Tested-by: Xufeng Zhang 
> ---
>  crypto/testmgr.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

Is there supposed to be another patch that contains test vectors?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH v5 17/17] Documentation: PCI: Add userguide for PCI endpoint NTB function

[Kishon Vijay Abraham I]

Add documentation to help users use pci-epf-ntb function driver and
existing host side NTB infrastructure for NTB functionality.

Signed-off-by: Kishon Vijay Abraham I 
Reviewed-by: Randy Dunlap 
---
 Documentation/PCI/endpoint/index.rst |   1 +
 Documentation/PCI/endpoint/pci-ntb-howto.rst | 160 +++
 2 files changed, 161 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-howto.rst

diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index 9cb6e5f3c4d5..38ea1f604b6d 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -12,6 +12,7 @@ PCI Endpoint Framework
pci-test-function
pci-test-howto
pci-ntb-function
+   pci-ntb-howto
 
function/binding/pci-test
function/binding/pci-ntb
diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst 
b/Documentation/PCI/endpoint/pci-ntb-howto.rst
new file mode 100644
index ..b6e1073c9a39
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst
@@ -0,0 +1,160 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===
+PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
+===
+
+:Author: Kishon Vijay Abraham I 
+
+This document is a guide to help users use pci-epf-ntb function driver
+and ntb_hw_epf host driver for NTB functionality. The list of steps to
+be followed in the host side and EP side is given below. For the hardware
+configuration and internals of NTB using configurable endpoints see
+Documentation/PCI/endpoint/pci-ntb-function.rst
+
+Endpoint Device
+===
+
+Endpoint Controller Devices
+---
+
+For implementing NTB functionality at least two endpoint controller devices
+are required.
+To find the list of endpoint controller devices in the system::
+
+# ls /sys/class/pci_epc/
+  290.pcie-ep  291.pcie-ep
+
+If PCI_ENDPOINT_CONFIGFS is enabled::
+
+   # ls /sys/kernel/config/pci_ep/controllers
+ 290.pcie-ep  291.pcie-ep
+
+
+Endpoint Function Drivers
+-
+
+To find the list of endpoint function drivers in the system::
+
+   # ls /sys/bus/pci-epf/drivers
+ pci_epf_ntb   pci_epf_ntb
+
+If PCI_ENDPOINT_CONFIGFS is enabled::
+
+   # ls /sys/kernel/config/pci_ep/functions
+ pci_epf_ntb   pci_epf_ntb
+
+
+Creating pci-epf-ntb Device
+
+
+PCI endpoint function device can be created using the configfs. To create
+pci-epf-ntb device, the following commands can be used::
+
+   # mount -t configfs none /sys/kernel/config
+   # cd /sys/kernel/config/pci_ep/
+   # mkdir functions/pci_epf_ntb/func1
+
+The "mkdir func1" above creates the pci-epf-ntb function device that will
+be probed by pci_epf_ntb driver.
+
+The PCI endpoint framework populates the directory with the following
+configurable fields::
+
+   # ls functions/pci_epf_ntb/func1
+  baseclass_codedeviceid  msi_interruptspci-epf-ntb.0
+  progif_code   secondary subsys_id vendorid
+  cache_line_size   interrupt_pin msix_interrupts   primary
+  revid subclass_code subsys_vendor_id
+
+The PCI endpoint function driver populates these entries with default values
+when the device is bound to the driver. The pci-epf-ntb driver populates
+vendorid with 0x and interrupt_pin with 0x0001::
+
+   # cat functions/pci_epf_ntb/func1/vendorid
+ 0x
+   # cat functions/pci_epf_ntb/func1/interrupt_pin
+ 0x0001
+
+
+Configuring pci-epf-ntb Device
+---
+
+The user can configure the pci-epf-ntb device using its configfs entry. In 
order
+to change the vendorid and the deviceid, the following
+commands can be used::
+
+   # echo 0x104c > functions/pci_epf_ntb/func1/vendorid
+   # echo 0xb00d > functions/pci_epf_ntb/func1/deviceid
+
+In order to configure NTB specific attributes, a new sub-directory to func1
+should be created::
+
+   # mkdir functions/pci_epf_ntb/func1/pci_epf_ntb.0/
+
+The NTB function driver will populate this directory with various attributes
+that can be configured by the user::
+
+   # ls functions/pci_epf_ntb/func1/pci_epf_ntb.0/
+  db_countmw1 mw2 mw3 mw4 num_mws
+  spad_count
+
+A sample configuration for NTB function is given below::
+
+   # echo 4 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/db_count
+   # echo 128 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/spad_count
+   # echo 2 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/num_mws
+   # echo 0x10 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw1
+   # echo 0x10 > functions/pci_epf_ntb/func1/pci_epf_ntb.0/mw2
+
+Binding pci-epf-ntb Device to EP Controller
+

[PATCH v5 16/17] Documentation: PCI: Add configfs binding documentation for pci-ntb endpoint function

[Kishon Vijay Abraham I]

Add binding documentation for pci-ntb endpoint function that helps in
adding and configuring pci-ntb endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../PCI/endpoint/function/binding/pci-ntb.rst | 38 +++
 Documentation/PCI/endpoint/index.rst  |  1 +
 2 files changed, 39 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-ntb.rst

diff --git a/Documentation/PCI/endpoint/function/binding/pci-ntb.rst 
b/Documentation/PCI/endpoint/function/binding/pci-ntb.rst
new file mode 100644
index ..40253d3d5163
--- /dev/null
+++ b/Documentation/PCI/endpoint/function/binding/pci-ntb.rst
@@ -0,0 +1,38 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==
+PCI NTB Endpoint Function
+==
+
+1) Create a subdirectory to pci_epf_ntb directory in configfs.
+
+Standard EPF Configurable Fields:
+
+   ===
+vendorid  should be 0x104c
+deviceid  should be 0xb00d for TI's J721E SoC
+revid don't care
+progif_code   don't care
+subclass_code should be 0x00
+baseclass_codeshould be 0x5
+cache_line_size   don't care
+subsys_vendor_id   don't care
+subsys_id don't care
+interrupt_pin don't care
+msi_interruptsdon't care
+msix_interrupts   don't care
+   ===
+
+2) Create a subdirectory to directory created in 1
+
+NTB EPF specific configurable fields:
+
+   ===
+db_count  Number of doorbells; default = 4
+mw1   size of memory window1
+mw2   size of memory window2
+mw3   size of memory window3
+mw4   size of memory window4
+num_mws   Number of memory windows; max = 4
+spad_countNumber of scratchpad registers; default = 64
+   ===
diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index ef6861128506..9cb6e5f3c4d5 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -14,3 +14,4 @@ PCI Endpoint Framework
pci-ntb-function
 
function/binding/pci-test
+   function/binding/pci-ntb
-- 
2.17.1

[PATCH v5 11/17] PCI: cadence: Implement ->msi_map_irq() ops

[Kishon Vijay Abraham I]

Implement ->msi_map_irq() ops in order to map physical address to
MSI address and return MSI data.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../pci/controller/cadence/pcie-cadence-ep.c  | 50 +++
 drivers/pci/endpoint/pci-epc-core.c   |  7 ++-
 include/linux/pci-epc.h   |  2 +-
 3 files changed, 54 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/controller/cadence/pcie-cadence-ep.c 
b/drivers/pci/controller/cadence/pcie-cadence-ep.c
index 254a3e1eff50..b9aacd6ce816 100644
--- a/drivers/pci/controller/cadence/pcie-cadence-ep.c
+++ b/drivers/pci/controller/cadence/pcie-cadence-ep.c
@@ -383,6 +383,54 @@ static int cdns_pcie_ep_send_msi_irq(struct cdns_pcie_ep 
*ep, u8 fn,
return 0;
 }
 
+static int cdns_pcie_ep_map_msi_irq(struct pci_epc *epc, u8 fn,
+   phys_addr_t addr, u8 interrupt_num,
+   u32 entry_size, u32 *msi_data)
+{
+   struct cdns_pcie_ep *ep = epc_get_drvdata(epc);
+   u32 cap = CDNS_PCIE_EP_FUNC_MSI_CAP_OFFSET;
+   struct cdns_pcie *pcie = &ep->pcie;
+   u16 flags, mme, data, data_mask;
+   u8 msi_count;
+   u64 pci_addr;
+   int ret;
+   int i;
+
+   /* Check whether the MSI feature has been enabled by the PCI host. */
+   flags = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_FLAGS);
+   if (!(flags & PCI_MSI_FLAGS_ENABLE))
+   return -EINVAL;
+
+   /* Get the number of enabled MSIs */
+   mme = (flags & PCI_MSI_FLAGS_QSIZE) >> 4;
+   msi_count = 1 << mme;
+   if (!interrupt_num || interrupt_num > msi_count)
+   return -EINVAL;
+
+   /* Compute the data value to be written. */
+   data_mask = msi_count - 1;
+   data = cdns_pcie_ep_fn_readw(pcie, fn, cap + PCI_MSI_DATA_64);
+   data = data & ~data_mask;
+
+   /* Get the PCI address where to write the data into. */
+   pci_addr = cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_HI);
+   pci_addr <<= 32;
+   pci_addr |= cdns_pcie_ep_fn_readl(pcie, fn, cap + PCI_MSI_ADDRESS_LO);
+   pci_addr &= GENMASK_ULL(63, 2);
+
+   for (i = 0; i < interrupt_num; i++) {
+   ret = cdns_pcie_ep_map_addr(epc, fn, addr, pci_addr,
+   entry_size);
+   if (ret)
+   return ret;
+   addr = addr + entry_size;
+   }
+
+   *msi_data = data;
+
+   return 0;
+}
+
 static int cdns_pcie_ep_send_msix_irq(struct cdns_pcie_ep *ep, u8 fn,
  u16 interrupt_num)
 {
@@ -482,6 +530,7 @@ static const struct pci_epc_features cdns_pcie_epc_features 
= {
.linkup_notifier = false,
.msi_capable = true,
.msix_capable = true,
+   .align = 256,
 };
 
 static const struct pci_epc_features*
@@ -501,6 +550,7 @@ static const struct pci_epc_ops cdns_pcie_epc_ops = {
.set_msix   = cdns_pcie_ep_set_msix,
.get_msix   = cdns_pcie_ep_get_msix,
.raise_irq  = cdns_pcie_ep_raise_irq,
+   .map_msi_irq= cdns_pcie_ep_map_msi_irq,
.start  = cdns_pcie_ep_start,
.get_features   = cdns_pcie_ep_get_features,
 };
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 73f9ff425824..d1e25be74665 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -235,7 +235,6 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  * MSI data
  * @epc: the EPC device which has the MSI capability
  * @func_no: the physical endpoint function number in the EPC device
- * @vfunc_no: the virtual endpoint function number in the physical function
  * @phys_addr: the physical address of the outbound region
  * @interrupt_num: the MSI interrupt number
  * @entry_size: Size of Outbound address region for each interrupt
@@ -249,7 +248,7 @@ EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
  * physical address (in outbound region) of the other interface to ring
  * doorbell.
  */
-int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no,
phys_addr_t phys_addr, u8 interrupt_num, u32 entry_size,
u32 *msi_data)
 {
@@ -262,8 +261,8 @@ int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 
vfunc_no,
return -EINVAL;
 
mutex_lock(&epc->lock);
-   ret = epc->ops->map_msi_irq(epc, func_no, vfunc_no, phys_addr,
-   interrupt_num, entry_size, msi_data);
+   ret = epc->ops->map_msi_irq(epc, func_no, phys_addr, interrupt_num,
+   entry_size, msi_data);
mutex_unlock(&epc->lock);
 
return ret;
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index 88284f3a0698..61f2cebcd272 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -78,7 +

[PATCH v5 12/17] PCI: endpoint: Add EP function driver to provide NTB functionality

[Kishon Vijay Abraham I]

Add a new endpoint function driver to provide NTB functionality
using multiple PCIe endpoint instances.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/Kconfig   |   12 +
 drivers/pci/endpoint/functions/Makefile  |1 +
 drivers/pci/endpoint/functions/pci-epf-ntb.c | 2106 ++
 3 files changed, 2119 insertions(+)
 create mode 100644 drivers/pci/endpoint/functions/pci-epf-ntb.c

diff --git a/drivers/pci/endpoint/functions/Kconfig 
b/drivers/pci/endpoint/functions/Kconfig
index 8820d0f7ec77..55ac7bb2d469 100644
--- a/drivers/pci/endpoint/functions/Kconfig
+++ b/drivers/pci/endpoint/functions/Kconfig
@@ -12,3 +12,15 @@ config PCI_EPF_TEST
   for PCI Endpoint.
 
   If in doubt, say "N" to disable Endpoint test driver.
+
+config PCI_EPF_NTB
+   tristate "PCI Endpoint NTB driver"
+   depends on PCI_ENDPOINT
+   help
+  Select this configuration option to enable the NTB driver
+  for PCI Endpoint. NTB driver implements NTB controller
+  functionality using multiple PCIe endpoint instances. It
+  can support NTB endpoint function devices created using
+  device tree.
+
+  If in doubt, say "N" to disable Endpoint NTB driver.
diff --git a/drivers/pci/endpoint/functions/Makefile 
b/drivers/pci/endpoint/functions/Makefile
index d6fafff080e2..96ab932a537a 100644
--- a/drivers/pci/endpoint/functions/Makefile
+++ b/drivers/pci/endpoint/functions/Makefile
@@ -4,3 +4,4 @@
 #
 
 obj-$(CONFIG_PCI_EPF_TEST) += pci-epf-test.o
+obj-$(CONFIG_PCI_EPF_NTB)  += pci-epf-ntb.o
diff --git a/drivers/pci/endpoint/functions/pci-epf-ntb.c 
b/drivers/pci/endpoint/functions/pci-epf-ntb.c
new file mode 100644
index ..e4778b782cd4
--- /dev/null
+++ b/drivers/pci/endpoint/functions/pci-epf-ntb.c
@@ -0,0 +1,2106 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Endpoint Function Driver to implement Non-Transparent Bridge functionality
+ *
+ * Copyright (C) 2020 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ */
+
+/*
+ *The PCI NTB function driver configures the SoC with multiple PCIe 
Endpoint(EP)
+ *controller instances (see diagram below) in such a way that transaction from
+ *one EP controller is routed to the other EP controller. Once PCI NTB function
+ *driver configures the SoC with multiple EP instances, HOST1 and HOST2 can
+ *communicate with each other using SoC as a bridge.
+ *
+ *   +-+   +-+
+ *   | |   | |
+ *   |HOST1|   |HOST2|
+ *   | |   | |
+ *   +--^--+   +--^--+
+ *  | |
+ *  | |
+ *+-|-|-+
+ *|  +--v--+   +--v--+  |
+ *|  | |   | |  |
+ *|  | EP  |   | EP  |  |
+ *|  | CONTROLLER1 |   | CONTROLLER2 |  |
+ *|  | <---> |  |
+ *|  | |   | |  |
+ *|  | |   | |  |
+ *|  | |  SoC With Multiple EP Instances   | |  |
+ *|  | |  (Configured using NTB Function)  | |  |
+ *|  +-+   +-+  |
+ *+-+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct workqueue_struct *kpcintb_workqueue;
+
+#define COMMAND_CONFIGURE_DOORBELL 1
+#define COMMAND_TEARDOWN_DOORBELL  2
+#define COMMAND_CONFIGURE_MW   3
+#define COMMAND_TEARDOWN_MW4
+#define COMMAND_LINK_UP5
+#define COMMAND_LINK_DOWN  6
+
+#define COMMAND_STATUS_OK  1
+#define COMMAND_STATUS_ERROR   2
+
+#define LINK_STATUS_UP BIT(0)
+
+#define SPAD_COUNT 64
+#define DB_COUNT   4
+#define NTB_MW_OFFSET  2
+#define DB_COUNT_MASK  GENMASK(15, 0)
+#define MSIX_ENABLEBIT(16)
+#define MAX_DB_COUNT   32
+#define MAX_MW 4
+
+enum epf_ntb_bar {
+   BAR_CONFIG,
+   BAR_PEER_SPAD,
+   BAR_DB_MW1,
+   BAR_MW2,
+   BAR_MW3,
+   BAR_MW4,
+};
+
+struct epf_ntb {
+   u32 num_mws;
+   u32 db_count;
+   u32 spad_count;
+   struct pci_epf *epf;
+   u64 mws_size[MAX_MW];
+   struct con

[PATCH v5 15/17] NTB: tool: Enable the NTB/PCIe link on the local or remote side of bridge

[Kishon Vijay Abraham I]

Invoke ntb_link_enable() to enable the NTB/PCIe link on the local
or remote side of the bridge.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/ntb/test/ntb_tool.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/ntb/test/ntb_tool.c b/drivers/ntb/test/ntb_tool.c
index b7bf3f863d79..8230ced503e3 100644
--- a/drivers/ntb/test/ntb_tool.c
+++ b/drivers/ntb/test/ntb_tool.c
@@ -1638,6 +1638,7 @@ static int tool_probe(struct ntb_client *self, struct 
ntb_dev *ntb)
 
tool_setup_dbgfs(tc);
 
+   ntb_link_enable(ntb, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);
return 0;
 
 err_clear_mws:
-- 
2.17.1

[PATCH v5 14/17] NTB: Add support for EPF PCI-Express Non-Transparent Bridge

[Kishon Vijay Abraham I]

Add support for EPF PCI-Express Non-Transparent Bridge (NTB) device.
This driver is platform independent and could be used by any platform
which have multiple PCIe endpoint instances configured using the
pci-epf-ntb driver. The driver connnects to the standard NTB sub-system
interface. The EPF NTB device has configurable number of memory windows
(Max 4), configurable number of doorbell (Max 32), and configurable
number of scratch-pad registers.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/ntb/hw/Kconfig  |   1 +
 drivers/ntb/hw/Makefile |   1 +
 drivers/ntb/hw/epf/Kconfig  |   6 +
 drivers/ntb/hw/epf/Makefile |   1 +
 drivers/ntb/hw/epf/ntb_hw_epf.c | 751 
 5 files changed, 760 insertions(+)
 create mode 100644 drivers/ntb/hw/epf/Kconfig
 create mode 100644 drivers/ntb/hw/epf/Makefile
 create mode 100644 drivers/ntb/hw/epf/ntb_hw_epf.c

diff --git a/drivers/ntb/hw/Kconfig b/drivers/ntb/hw/Kconfig
index e77c587060ff..c325be526b80 100644
--- a/drivers/ntb/hw/Kconfig
+++ b/drivers/ntb/hw/Kconfig
@@ -2,4 +2,5 @@
 source "drivers/ntb/hw/amd/Kconfig"
 source "drivers/ntb/hw/idt/Kconfig"
 source "drivers/ntb/hw/intel/Kconfig"
+source "drivers/ntb/hw/epf/Kconfig"
 source "drivers/ntb/hw/mscc/Kconfig"
diff --git a/drivers/ntb/hw/Makefile b/drivers/ntb/hw/Makefile
index 4714d6238845..223ca592b5f9 100644
--- a/drivers/ntb/hw/Makefile
+++ b/drivers/ntb/hw/Makefile
@@ -2,4 +2,5 @@
 obj-$(CONFIG_NTB_AMD)  += amd/
 obj-$(CONFIG_NTB_IDT)  += idt/
 obj-$(CONFIG_NTB_INTEL)+= intel/
+obj-$(CONFIG_NTB_EPF)  += epf/
 obj-$(CONFIG_NTB_SWITCHTEC) += mscc/
diff --git a/drivers/ntb/hw/epf/Kconfig b/drivers/ntb/hw/epf/Kconfig
new file mode 100644
index ..6197d1aab344
--- /dev/null
+++ b/drivers/ntb/hw/epf/Kconfig
@@ -0,0 +1,6 @@
+config NTB_EPF
+   tristate "Generic EPF Non-Transparent Bridge support"
+   depends on m
+   help
+ This driver supports EPF NTB on configurable endpoint.
+ If unsure, say N.
diff --git a/drivers/ntb/hw/epf/Makefile b/drivers/ntb/hw/epf/Makefile
new file mode 100644
index ..2f560a422bc6
--- /dev/null
+++ b/drivers/ntb/hw/epf/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_NTB_EPF) += ntb_hw_epf.o
diff --git a/drivers/ntb/hw/epf/ntb_hw_epf.c b/drivers/ntb/hw/epf/ntb_hw_epf.c
new file mode 100644
index ..2989f2b41fda
--- /dev/null
+++ b/drivers/ntb/hw/epf/ntb_hw_epf.c
@@ -0,0 +1,751 @@
+// SPDX-License-Identifier: GPL-2.0
+/**
+ * Host side endpoint driver to implement Non-Transparent Bridge functionality
+ *
+ * Copyright (C) 2020 Texas Instruments
+ * Author: Kishon Vijay Abraham I 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define NTB_EPF_COMMAND0x0
+#define CMD_CONFIGURE_DOORBELL 1
+#define CMD_TEARDOWN_DOORBELL  2
+#define CMD_CONFIGURE_MW   3
+#define CMD_TEARDOWN_MW4
+#define CMD_LINK_UP5
+#define CMD_LINK_DOWN  6
+
+#define NTB_EPF_ARGUMENT   0x4
+#define MSIX_ENABLEBIT(16)
+
+#define NTB_EPF_CMD_STATUS 0x8
+#define COMMAND_STATUS_OK  1
+#define COMMAND_STATUS_ERROR   2
+
+#define NTB_EPF_LINK_STATUS0x0A
+#define LINK_STATUS_UP BIT(0)
+
+#define NTB_EPF_TOPOLOGY   0x0C
+#define NTB_EPF_LOWER_ADDR 0x10
+#define NTB_EPF_UPPER_ADDR 0x14
+#define NTB_EPF_LOWER_SIZE 0x18
+#define NTB_EPF_UPPER_SIZE 0x1C
+#define NTB_EPF_MW_COUNT   0x20
+#define NTB_EPF_MW1_OFFSET 0x24
+#define NTB_EPF_SPAD_OFFSET0x28
+#define NTB_EPF_SPAD_COUNT 0x2C
+#define NTB_EPF_DB_ENTRY_SIZE  0x30
+#define NTB_EPF_DB_DATA(n) (0x34 + (n) * 4)
+
+#define NTB_EPF_MIN_DB_COUNT   3
+#define NTB_EPF_MAX_DB_COUNT   31
+#define NTB_EPF_MW_OFFSET  2
+
+#define NTB_EPF_COMMAND_TIMEOUT1000 /* 1 Sec */
+
+enum pci_barno {
+   BAR_0,
+   BAR_1,
+   BAR_2,
+   BAR_3,
+   BAR_4,
+   BAR_5,
+};
+
+struct ntb_epf_dev {
+   struct ntb_dev ntb;
+   struct device *dev;
+   /* Mutex to protect providing commands to NTB EPF */
+   struct mutex cmd_lock;
+
+   enum pci_barno ctrl_reg_bar;
+   enum pci_barno peer_spad_reg_bar;
+   enum pci_barno db_reg_bar;
+
+   unsigned int mw_count;
+   unsigned int spad_count;
+   unsigned int db_count;
+
+   void __iomem *ctrl_reg;
+   void __iomem *db_reg;
+   void __iomem *peer_spad_reg;
+
+   unsigned int self_spad;
+   unsigned int peer_spad;
+
+   int db_val;
+   u64 db_valid_mask;
+};
+
+#define ntb_ndev(__ntb) container_of(__ntb, struct ntb_epf_dev, ntb)
+
+struct ntb_epf_data {
+   /* BAR that contains both control region and self spad region */
+   enum pci_barno ctrl_reg_bar;
+   /* BAR that contains peer spad region */
+   enum pci_barno peer_spad_reg_bar;
+   /* BAR that contains Doorbell region and Memory window '1' */
+   enum pci_barno db_reg_bar;
+};
+
+static int ntb_epf_send_command(struct ntb_epf_de

[PATCH v5 13/17] PCI: Add TI J721E device to pci ids

[Kishon Vijay Abraham I]

Add TI J721E device to the pci id database. Since this device has
a configurable PCIe endpoint, it could be used with different
drivers.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/misc/pci_endpoint_test.c | 1 -
 include/linux/pci_ids.h  | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/pci_endpoint_test.c b/drivers/misc/pci_endpoint_test.c
index e060796f9caa..03fade34aeac 100644
--- a/drivers/misc/pci_endpoint_test.c
+++ b/drivers/misc/pci_endpoint_test.c
@@ -68,7 +68,6 @@
 #define PCI_ENDPOINT_TEST_FLAGS0x2c
 #define FLAG_USE_DMA   BIT(0)
 
-#define PCI_DEVICE_ID_TI_J721E 0xb00d
 #define PCI_DEVICE_ID_TI_AM654 0xb00c
 
 #define is_am654_pci_dev(pdev) \
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 1ab1e24bcbce..6ddeb64049b5 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -880,6 +880,7 @@
 #define PCI_DEVICE_ID_TI_X620  0xac8d
 #define PCI_DEVICE_ID_TI_X420  0xac8e
 #define PCI_DEVICE_ID_TI_XX20_FM   0xac8f
+#define PCI_DEVICE_ID_TI_J721E 0xb00d
 #define PCI_DEVICE_ID_TI_DRA74x0xb500
 #define PCI_DEVICE_ID_TI_DRA72x0xb501
 
-- 
2.17.1

[PATCH v5 10/17] PCI: endpoint: Allow user to create sub-directory of 'EPF Device' directory

[Kishon Vijay Abraham I]

Documentation/PCI/endpoint/pci-endpoint-cfs.rst explains how a user
has to create a directory in-order to create a 'EPF Device' that
can be configured/probed by 'EPF Driver'.

Allow user to create a sub-directory of 'EPF Device' directory for
any function specific attributes that has to be exposed to the user.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-ep-cfs.c | 23 +++
 include/linux/pci-epf.h   |  3 +++
 2 files changed, 26 insertions(+)

diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 8f750961d6ab..f3a8b833b479 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -490,7 +490,29 @@ static struct configfs_item_operations pci_epf_ops = {
.release= pci_epf_release,
 };
 
+static struct config_group *pci_epf_type_make(struct config_group *group,
+ const char *name)
+{
+   struct pci_epf_group *epf_group = to_pci_epf_group(&group->cg_item);
+   struct config_group *epf_type_group;
+
+   epf_type_group = pci_epf_type_add_cfs(epf_group->epf, group);
+   return epf_type_group;
+}
+
+static void pci_epf_type_drop(struct config_group *group,
+ struct config_item *item)
+{
+   config_item_put(item);
+}
+
+static struct configfs_group_operations pci_epf_type_group_ops = {
+   .make_group = &pci_epf_type_make,
+   .drop_item  = &pci_epf_type_drop,
+};
+
 static const struct config_item_type pci_epf_type = {
+   .ct_group_ops   = &pci_epf_type_group_ops,
.ct_item_ops= &pci_epf_ops,
.ct_attrs   = pci_epf_attrs,
.ct_owner   = THIS_MODULE,
@@ -553,6 +575,7 @@ static struct config_group *pci_epf_make(struct 
config_group *group,
goto free_name;
}
 
+   epf->group = &epf_group->group;
epf_group->epf = epf;
 
kfree(epf_name);
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index b241e7dd171f..6833e2160ef1 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -9,6 +9,7 @@
 #ifndef __LINUX_PCI_EPF_H
 #define __LINUX_PCI_EPF_H
 
+#include 
 #include 
 #include 
 #include 
@@ -128,6 +129,7 @@ struct pci_epf_bar {
  *   EPC device
  * @sec_epc_bar: represents the BAR of EPF device associated with secondary EPC
  * @sec_epc_func_no: unique (physical) function number within the secondary EPC
+ * @group: configfs group associated with the EPF device
  */
 struct pci_epf {
struct device   dev;
@@ -150,6 +152,7 @@ struct pci_epf {
struct list_headsec_epc_list;
struct pci_epf_bar  sec_epc_bar[6];
u8  sec_epc_func_no;
+   struct config_group *group;
 };
 
 /**
-- 
2.17.1

[PATCH v2] remoteproc/mediatek: Add support for mt8192 SCP

[Pi-Hsun Shih]

Add support for mt8192 SCP.

Signed-off-by: Pi-Hsun Shih 
Reviewed-by: Tzung-Bi Shih 
---

Change since v1:
* Remove unused register definitions.

---
 drivers/remoteproc/mtk_common.h  |  32 +
 drivers/remoteproc/mtk_scp.c | 207 ++-
 drivers/remoteproc/mtk_scp_ipi.c |   5 +-
 3 files changed, 211 insertions(+), 33 deletions(-)

diff --git a/drivers/remoteproc/mtk_common.h b/drivers/remoteproc/mtk_common.h
index 0066c83636d0..47b4561443a9 100644
--- a/drivers/remoteproc/mtk_common.h
+++ b/drivers/remoteproc/mtk_common.h
@@ -32,6 +32,23 @@
 #define MT8183_SCP_CACHESIZE_8KB   BIT(8)
 #define MT8183_SCP_CACHE_CON_WAYEN BIT(10)
 
+#define MT8192_L2TCM_SRAM_PD_0 0x210C0
+#define MT8192_L2TCM_SRAM_PD_1 0x210C4
+#define MT8192_L2TCM_SRAM_PD_2 0x210C8
+#define MT8192_L1TCM_SRAM_PDN  0x2102C
+#define MT8192_CPU0_SRAM_PD0x21080
+
+#define MT8192_SCP2APMCU_IPC_SET   0x24080
+#define MT8192_SCP2APMCU_IPC_CLR   0x24084
+#define MT8192_SCP_IPC_INT_BIT BIT(0)
+#define MT8192_SCP2SPM_IPC_CLR 0x24094
+#define MT8192_GIPC_IN_SET 0x24098
+#define MT8192_HOST_IPC_INT_BITBIT(0)
+
+#define MT8192_CORE0_SW_RSTN_CLR   0x3
+#define MT8192_CORE0_SW_RSTN_SET   0x30004
+#define MT8192_CORE0_WDT_CFG   0x30034
+
 #define SCP_FW_VER_LEN 32
 #define SCP_SHARE_BUFFER_SIZE  288
 
@@ -50,6 +67,19 @@ struct scp_ipi_desc {
void *priv;
 };
 
+struct mtk_scp;
+
+struct mtk_scp_of_data {
+   int (*scp_before_load)(struct mtk_scp *scp);
+   void (*scp_irq_handler)(struct mtk_scp *scp);
+   void (*scp_reset_assert)(struct mtk_scp *scp);
+   void (*scp_reset_deassert)(struct mtk_scp *scp);
+   void (*scp_stop)(struct mtk_scp *scp);
+
+   u32 host_to_scp_reg;
+   u32 host_to_scp_int_bit;
+};
+
 struct mtk_scp {
struct device *dev;
struct rproc *rproc;
@@ -58,6 +88,8 @@ struct mtk_scp {
void __iomem *sram_base;
size_t sram_size;
 
+   const struct mtk_scp_of_data *data;
+
struct mtk_share_obj __iomem *recv_buf;
struct mtk_share_obj __iomem *send_buf;
struct scp_run run;
diff --git a/drivers/remoteproc/mtk_scp.c b/drivers/remoteproc/mtk_scp.c
index ac13e7b046a6..f5f226a7b34c 100644
--- a/drivers/remoteproc/mtk_scp.c
+++ b/drivers/remoteproc/mtk_scp.c
@@ -124,9 +124,6 @@ static int scp_ipi_init(struct mtk_scp *scp)
size_t send_offset = SCP_FW_END - sizeof(struct mtk_share_obj);
size_t recv_offset = send_offset - sizeof(struct mtk_share_obj);
 
-   /* Disable SCP to host interrupt */
-   writel(MT8183_SCP_IPC_INT_BIT, scp->reg_base + MT8183_SCP_TO_HOST);
-
/* shared buffer initialization */
scp->recv_buf =
(struct mtk_share_obj __iomem *)(scp->sram_base + recv_offset);
@@ -138,7 +135,7 @@ static int scp_ipi_init(struct mtk_scp *scp)
return 0;
 }
 
-static void scp_reset_assert(const struct mtk_scp *scp)
+static void mt8183_scp_reset_assert(struct mtk_scp *scp)
 {
u32 val;
 
@@ -147,7 +144,7 @@ static void scp_reset_assert(const struct mtk_scp *scp)
writel(val, scp->reg_base + MT8183_SW_RSTN);
 }
 
-static void scp_reset_deassert(const struct mtk_scp *scp)
+static void mt8183_scp_reset_deassert(struct mtk_scp *scp)
 {
u32 val;
 
@@ -156,17 +153,29 @@ static void scp_reset_deassert(const struct mtk_scp *scp)
writel(val, scp->reg_base + MT8183_SW_RSTN);
 }
 
-static irqreturn_t scp_irq_handler(int irq, void *priv)
+static void mt8192_scp_reset_assert(struct mtk_scp *scp)
 {
-   struct mtk_scp *scp = priv;
-   u32 scp_to_host;
-   int ret;
+   writel(1, scp->reg_base + MT8192_CORE0_SW_RSTN_SET);
+}
 
-   ret = clk_prepare_enable(scp->clk);
-   if (ret) {
-   dev_err(scp->dev, "failed to enable clocks\n");
-   return IRQ_NONE;
-   }
+static void mt8192_scp_reset_deassert(struct mtk_scp *scp)
+{
+   writel(1, scp->reg_base + MT8192_CORE0_SW_RSTN_CLR);
+}
+
+static void scp_reset_assert(struct mtk_scp *scp)
+{
+   scp->data->scp_reset_assert(scp);
+}
+
+static void scp_reset_deassert(struct mtk_scp *scp)
+{
+   scp->data->scp_reset_deassert(scp);
+}
+
+static void mt8183_scp_irq_handler(struct mtk_scp *scp)
+{
+   u32 scp_to_host;
 
scp_to_host = readl(scp->reg_base + MT8183_SCP_TO_HOST);
if (scp_to_host & MT8183_SCP_IPC_INT_BIT)
@@ -177,6 +186,40 @@ static irqreturn_t scp_irq_handler(int irq, void *priv)
/* SCP won't send another interrupt until we set SCP_TO_HOST to 0. */
writel(MT8183_SCP_IPC_INT_BIT | MT8183_SCP_WDT_INT_BIT,
   scp->reg_base + MT8183_SCP_TO_HOST);
+}
+
+static void mt8192_scp_irq_handler(struct mtk_scp *scp)
+{
+   u32 scp_to_host;
+
+   scp_to_host = readl(scp->reg_base + MT8192_SCP2APMCU_IPC_SET);
+
+   if (scp_to_host & MT8192_SCP_IPC_INT_BIT)
+  

[PATCH v5 08/17] PCI: endpoint: Add pci_epc_ops to map MSI irq

[Kishon Vijay Abraham I]

Add pci_epc_ops to map physical address to MSI address and return MSI
data. The physical address is an address in the outbound region. This is
required to implement doorbell functionality of NTB (non transparent
bridge) wherein EPC on either side of the interface (primary and
secondary) can directly write to the physical address (in outbound
region) of the other interface to ring doorbell using MSI.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 40 +
 include/linux/pci-epc.h |  7 +
 2 files changed, 47 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 0f6e2364ae6f..73f9ff425824 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -230,6 +230,46 @@ int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
 }
 EXPORT_SYMBOL_GPL(pci_epc_raise_irq);
 
+/**
+ * pci_epc_map_msi_irq() - Map physical address to MSI address and return
+ * MSI data
+ * @epc: the EPC device which has the MSI capability
+ * @func_no: the physical endpoint function number in the EPC device
+ * @vfunc_no: the virtual endpoint function number in the physical function
+ * @phys_addr: the physical address of the outbound region
+ * @interrupt_num: the MSI interrupt number
+ * @entry_size: Size of Outbound address region for each interrupt
+ * @msi_data: the data that should be written in order to raise MSI interrupt
+ *with interrupt number as 'interrupt num'
+ *
+ * Invoke to map physical address to MSI address and return MSI data. The
+ * physical address should be an address in the outbound region. This is
+ * required to implement doorbell functionality of NTB wherein EPC on either
+ * side of the interface (primary and secondary) can directly write to the
+ * physical address (in outbound region) of the other interface to ring
+ * doorbell.
+ */
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+   phys_addr_t phys_addr, u8 interrupt_num, u32 entry_size,
+   u32 *msi_data)
+{
+   int ret;
+
+   if (IS_ERR_OR_NULL(epc))
+   return -EINVAL;
+
+   if (!epc->ops->map_msi_irq)
+   return -EINVAL;
+
+   mutex_lock(&epc->lock);
+   ret = epc->ops->map_msi_irq(epc, func_no, vfunc_no, phys_addr,
+   interrupt_num, entry_size, msi_data);
+   mutex_unlock(&epc->lock);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(pci_epc_map_msi_irq);
+
 /**
  * pci_epc_get_msi() - get the number of MSI interrupt numbers allocated
  * @epc: the EPC device to which MSI interrupts was requested
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index d9cb3944fb87..88284f3a0698 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -55,6 +55,7 @@ pci_epc_interface_string(enum pci_epc_interface_type type)
  * @get_msix: ops to get the number of MSI-X interrupts allocated by the RC
  *  from the MSI-X capability register
  * @raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
+ * @map_msi_irq: ops to map physical address to MSI address and return MSI data
  * @start: ops to start the PCI link
  * @stop: ops to stop the PCI link
  * @owner: the module owner containing the ops
@@ -77,6 +78,9 @@ struct pci_epc_ops {
int (*get_msix)(struct pci_epc *epc, u8 func_no);
int (*raise_irq)(struct pci_epc *epc, u8 func_no,
 enum pci_epc_irq_type type, u16 interrupt_num);
+   int (*map_msi_irq)(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
+  phys_addr_t phys_addr, u8 interrupt_num,
+  u32 entry_size, u32 *msi_data);
int (*start)(struct pci_epc *epc);
void(*stop)(struct pci_epc *epc);
const struct pci_epc_features* (*get_features)(struct pci_epc *epc,
@@ -216,6 +220,9 @@ int pci_epc_get_msi(struct pci_epc *epc, u8 func_no);
 int pci_epc_set_msix(struct pci_epc *epc, u8 func_no, u16 interrupts,
 enum pci_barno, u32 offset);
 int pci_epc_get_msix(struct pci_epc *epc, u8 func_no);
+int pci_epc_map_msi_irq(struct pci_epc *epc, u8 func_no,
+   phys_addr_t phys_addr, u8 interrupt_num,
+   u32 entry_size, u32 *msi_data);
 int pci_epc_raise_irq(struct pci_epc *epc, u8 func_no,
  enum pci_epc_irq_type type, u16 interrupt_num);
 int pci_epc_start(struct pci_epc *epc);
-- 
2.17.1

[PATCH v5 06/17] PCI: endpoint: Add support to associate secondary EPC with EPF

[Kishon Vijay Abraham I]

In the case of standard endpoint functions, only one endpoint
controller (EPC) will be associated with an endpoint function
(EPF). However for providing NTB (non transparent bridge)
functionality, two EPCs should be associated with a single EPF.
Add support to associate secondary EPC with EPF. This is in
preparation for adding NTB endpoint function driver.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 11 ++--
 drivers/pci/endpoint/pci-ep-cfs.c |  6 +-
 drivers/pci/endpoint/pci-epc-core.c   | 50 
 drivers/pci/endpoint/pci-epf-core.c   | 57 +--
 include/linux/pci-epc.h   | 25 +++-
 include/linux/pci-epf.h   | 17 +-
 6 files changed, 128 insertions(+), 38 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index 7a1f3abfde48..c0ac4e9cbe72 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -619,7 +619,8 @@ static void pci_epf_test_unbind(struct pci_epf *epf)
 
if (epf_test->reg[bar]) {
pci_epc_clear_bar(epc, epf->func_no, epf_bar);
-   pci_epf_free_space(epf, epf_test->reg[bar], bar);
+   pci_epf_free_space(epf, epf_test->reg[bar], bar,
+  PRIMARY_INTERFACE);
}
}
 }
@@ -651,7 +652,8 @@ static int pci_epf_test_set_bar(struct pci_epf *epf)
 
ret = pci_epc_set_bar(epc, epf->func_no, epf_bar);
if (ret) {
-   pci_epf_free_space(epf, epf_test->reg[bar], bar);
+   pci_epf_free_space(epf, epf_test->reg[bar], bar,
+  PRIMARY_INTERFACE);
dev_err(dev, "Failed to set BAR%d\n", bar);
if (bar == test_reg_bar)
return ret;
@@ -771,7 +773,7 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
}
 
base = pci_epf_alloc_space(epf, test_reg_size, test_reg_bar,
-  epc_features->align);
+  epc_features->align, PRIMARY_INTERFACE);
if (!base) {
dev_err(dev, "Failed to allocated register space\n");
return -ENOMEM;
@@ -789,7 +791,8 @@ static int pci_epf_test_alloc_space(struct pci_epf *epf)
continue;
 
base = pci_epf_alloc_space(epf, bar_size[bar], bar,
-  epc_features->align);
+  epc_features->align,
+  PRIMARY_INTERFACE);
if (!base)
dev_err(dev, "Failed to allocate space for BAR%d\n",
bar);
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 3710adf51912..6ca9e2f92460 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -94,13 +94,13 @@ static int pci_epc_epf_link(struct config_item *epc_item,
struct pci_epc *epc = epc_group->epc;
struct pci_epf *epf = epf_group->epf;
 
-   ret = pci_epc_add_epf(epc, epf);
+   ret = pci_epc_add_epf(epc, epf, PRIMARY_INTERFACE);
if (ret)
return ret;
 
ret = pci_epf_bind(epf);
if (ret) {
-   pci_epc_remove_epf(epc, epf);
+   pci_epc_remove_epf(epc, epf, PRIMARY_INTERFACE);
return ret;
}
 
@@ -120,7 +120,7 @@ static void pci_epc_epf_unlink(struct config_item *epc_item,
epc = epc_group->epc;
epf = epf_group->epf;
pci_epf_unbind(epf);
-   pci_epc_remove_epf(epc, epf);
+   pci_epc_remove_epf(epc, epf, PRIMARY_INTERFACE);
 }
 
 static struct configfs_item_operations pci_epc_item_ops = {
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index ea7e7465ce7a..0f6e2364ae6f 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -493,22 +493,32 @@ EXPORT_SYMBOL_GPL(pci_epc_write_header);
  * pci_epc_add_epf() - bind PCI endpoint function to an endpoint controller
  * @epc: the EPC device to which the endpoint function should be added
  * @epf: the endpoint function to be added
+ * @type: Identifies if the EPC is connected to the primary or secondary
+ *interface of EPF
  *
  * A PCI endpoint device can have one or more functions. In the case of PCIe,
  * the specification allows up to 8 PCIe endpoint functions. Invoke
  * pci_epc_add_epf() to add a PCI endpoint function to an endpoint controller.
  */
-int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf)
+int pci_epc_add_epf(struct pci_epc *epc, struct pci_epf *epf,
+   enum pci

[PATCH v5 09/17] PCI: endpoint: Add pci_epf_ops for epf drivers to expose function specific attrs

[Kishon Vijay Abraham I]

In addition to the attributes that are generic across function drivers
documented in Documentation/PCI/endpoint/pci-endpoint-cfs.rst, there
could be function specific attributes that has to be exposed by the
function driver to be configured by the user. Add ->add_cfs()
in pci_epf_ops to be populated by the function driver if it has to
expose any function specific attributes and pci_epf_type_add_cfs() to
be invoked by pci-ep-cfs.c when sub-directory to main function directory
is created.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epf-core.c | 32 +
 include/linux/pci-epf.h |  5 +
 2 files changed, 37 insertions(+)

diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index 79329ec6373c..7646c8660d42 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -20,6 +20,38 @@ static DEFINE_MUTEX(pci_epf_mutex);
 static struct bus_type pci_epf_bus_type;
 static const struct device_type pci_epf_type;
 
+/**
+ * pci_epf_type_add_cfs() - Help function drivers to expose function specific
+ *  attributes in configfs
+ * @epf: the EPF device that has to be configured using configfs
+ * @group: the parent configfs group (corresponding to entries in
+ * pci_epf_device_id)
+ *
+ * Invoke to expose function specific attributes in configfs. If the function
+ * driver does not have anything to expose (attributes configured by user),
+ * return NULL.
+ */
+struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
+ struct config_group *group)
+{
+   struct config_group *epf_type_group;
+
+   if (!epf->driver) {
+   dev_err(&epf->dev, "epf device not bound to driver\n");
+   return NULL;
+   }
+
+   if (!epf->driver->ops->add_cfs)
+   return NULL;
+
+   mutex_lock(&epf->lock);
+   epf_type_group = epf->driver->ops->add_cfs(epf, group);
+   mutex_unlock(&epf->lock);
+
+   return epf_type_group;
+}
+EXPORT_SYMBOL_GPL(pci_epf_type_add_cfs);
+
 /**
  * pci_epf_unbind() - Notify the function driver that the binding between the
  *   EPF device and EPC device has been lost
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 1dc66824f5a8..b241e7dd171f 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -62,10 +62,13 @@ struct pci_epf_header {
  * @bind: ops to perform when a EPC device has been bound to EPF device
  * @unbind: ops to perform when a binding has been lost between a EPC device
  * and EPF device
+ * @add_cfs: ops to initialize function specific configfs attributes
  */
 struct pci_epf_ops {
int (*bind)(struct pci_epf *epf);
void(*unbind)(struct pci_epf *epf);
+   struct config_group *(*add_cfs)(struct pci_epf *epf,
+   struct config_group *group);
 };
 
 /**
@@ -188,4 +191,6 @@ void pci_epf_free_space(struct pci_epf *epf, void *addr, 
enum pci_barno bar,
enum pci_epc_interface_type type);
 int pci_epf_bind(struct pci_epf *epf);
 void pci_epf_unbind(struct pci_epf *epf);
+struct config_group *pci_epf_type_add_cfs(struct pci_epf *epf,
+ struct config_group *group);
 #endif /* __LINUX_PCI_EPF_H */
-- 
2.17.1

[PATCH v5 05/17] PCI: endpoint: Remove unused pci_epf_match_device()

[Kishon Vijay Abraham I]

Remove unused pci_epf_match_device() function added in pci-epf-core.c

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epf-core.c | 16 
 include/linux/pci-epf.h |  2 --
 2 files changed, 18 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index c977cf9dce56..e44a317a2a2a 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -282,22 +282,6 @@ struct pci_epf *pci_epf_create(const char *name)
 }
 EXPORT_SYMBOL_GPL(pci_epf_create);
 
-const struct pci_epf_device_id *
-pci_epf_match_device(const struct pci_epf_device_id *id, struct pci_epf *epf)
-{
-   if (!id || !epf)
-   return NULL;
-
-   while (*id->name) {
-   if (strcmp(epf->name, id->name) == 0)
-   return id;
-   id++;
-   }
-
-   return NULL;
-}
-EXPORT_SYMBOL_GPL(pci_epf_match_device);
-
 static void pci_epf_dev_release(struct device *dev)
 {
struct pci_epf *epf = to_pci_epf(dev);
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index fa3aca43eb19..f373a134ac04 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -165,8 +165,6 @@ static inline void *epf_get_drvdata(struct pci_epf *epf)
return dev_get_drvdata(&epf->dev);
 }
 
-const struct pci_epf_device_id *
-pci_epf_match_device(const struct pci_epf_device_id *id, struct pci_epf *epf);
 struct pci_epf *pci_epf_create(const char *name);
 void pci_epf_destroy(struct pci_epf *epf);
 int __pci_epf_register_driver(struct pci_epf_driver *driver,
-- 
2.17.1

[PATCH v5 07/17] PCI: endpoint: Add support in configfs to associate two EPCs with EPF

[Kishon Vijay Abraham I]

Now that PCI endpoint core supports to add secondary endpoint
controller (EPC) with endpoint function (EPF), Add support in configfs
to associate two EPCs with EPF. This creates "primary" and "secondary"
directory inside the directory created by users for EPF device. Users
have to add a symlink of endpoint controller (pci_ep/controllers/) to
"primary" or "secondary" directory to bind EPF to primary and secondary
EPF interfaces respectively. Existing method of linking directory
representing EPF device to directory representing EPC device to
associate a single EPC device with a EPF device will continue to work.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../PCI/endpoint/pci-endpoint-cfs.rst |  10 ++
 drivers/pci/endpoint/pci-ep-cfs.c | 147 ++
 2 files changed, 157 insertions(+)

diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst 
b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
index 1bbd81ed06c8..696f8eeb4738 100644
--- a/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.rst
@@ -68,6 +68,16 @@ created)
... subsys_vendor_id
... subsys_id
... interrupt_pin
+... primary/
+   ... /
+... secondary/
+   ... /
+
+If an EPF device has to be associated with 2 EPCs (like in the case of
+Non-transparent bridge), symlink of endpoint controller connected to primary
+interface should be added in 'primary' directory and symlink of endpoint
+controller connected to secondary interface should be added in 'secondary'
+directory.
 
 EPC Device
 ==
diff --git a/drivers/pci/endpoint/pci-ep-cfs.c 
b/drivers/pci/endpoint/pci-ep-cfs.c
index 6ca9e2f92460..8f750961d6ab 100644
--- a/drivers/pci/endpoint/pci-ep-cfs.c
+++ b/drivers/pci/endpoint/pci-ep-cfs.c
@@ -21,6 +21,9 @@ static struct config_group *controllers_group;
 
 struct pci_epf_group {
struct config_group group;
+   struct config_group primary_epc_group;
+   struct config_group secondary_epc_group;
+   struct delayed_work cfs_work;
struct pci_epf *epf;
int index;
 };
@@ -41,6 +44,127 @@ static inline struct pci_epc_group *to_pci_epc_group(struct 
config_item *item)
return container_of(to_config_group(item), struct pci_epc_group, group);
 }
 
+static int pci_secondary_epc_epf_link(struct config_item *epf_item,
+ struct config_item *epc_item)
+{
+   int ret;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc = epc_group->epc;
+   struct pci_epf *epf = epf_group->epf;
+
+   ret = pci_epc_add_epf(epc, epf, SECONDARY_INTERFACE);
+   if (ret)
+   return ret;
+
+   ret = pci_epf_bind(epf);
+   if (ret) {
+   pci_epc_remove_epf(epc, epf, SECONDARY_INTERFACE);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void pci_secondary_epc_epf_unlink(struct config_item *epc_item,
+struct config_item *epf_item)
+{
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc;
+   struct pci_epf *epf;
+
+   WARN_ON_ONCE(epc_group->start);
+
+   epc = epc_group->epc;
+   epf = epf_group->epf;
+   pci_epf_unbind(epf);
+   pci_epc_remove_epf(epc, epf, SECONDARY_INTERFACE);
+}
+
+static struct configfs_item_operations pci_secondary_epc_item_ops = {
+   .allow_link = pci_secondary_epc_epf_link,
+   .drop_link  = pci_secondary_epc_epf_unlink,
+};
+
+static const struct config_item_type pci_secondary_epc_type = {
+   .ct_item_ops= &pci_secondary_epc_item_ops,
+   .ct_owner   = THIS_MODULE,
+};
+
+static struct config_group
+*pci_ep_cfs_add_secondary_group(struct pci_epf_group *epf_group)
+{
+   struct config_group *secondary_epc_group;
+
+   secondary_epc_group = &epf_group->secondary_epc_group;
+   config_group_init_type_name(secondary_epc_group, "secondary",
+   &pci_secondary_epc_type);
+   configfs_register_group(&epf_group->group, secondary_epc_group);
+
+   return secondary_epc_group;
+}
+
+static int pci_primary_epc_epf_link(struct config_item *epf_item,
+   struct config_item *epc_item)
+{
+   int ret;
+   struct pci_epf_group *epf_group = to_pci_epf_group(epf_item->ci_parent);
+   struct pci_epc_group *epc_group = to_pci_epc_group(epc_item);
+   struct pci_epc *epc = epc_group->epc;
+   struct pci_epf *epf = epf_group->epf;
+
+   ret = pci_epc_add_epf(epc, epf, PRIMARY_INTER

Re: [PATCH v2] sched, mm: Optimize current_gfp_context()

[Xu, Yanfei]

Hi Waiman,

On 8/12/20 6:29 AM, Andrew Morton wrote:

On Thu, 18 Jun 2020 17:29:36 -0400 Waiman Long  wrote:


The current_gfp_context() converts a number of PF_MEMALLOC_* per-process
flags into the corresponding GFP_* flags for memory allocation. In
that function, current->flags is accessed 3 times. That may lead to
duplicated access of the same memory location.


I have a puzzle about this comment, what's the meaning about "That may
lead to duplicated access of the same memory location". After using
variable 'pflags', will it not duplicated access the same memory
location?
Looking forward to your reply :)

Thanks,
Yanfei


This is not usually a problem with minimal debug config options on as the
compiler can optimize away the duplicated memory accesses.  With most
of the debug config options on, however, that may not be the case.
For example, the x86-64 object size of the __need_fs_reclaim() in a
debug kernel that calls current_gfp_context() was 309 bytes. With this
patch applied, the object size is reduced to 202 bytes. This is a saving
of 107 bytes and will probably be slightly faster too.

...

--- a/include/linux/sched/mm.h
+++ b/include/linux/sched/mm.h
@@ -181,18 +181,20 @@ static inline bool in_vfork(struct task_struct *tsk)
   */
  static inline gfp_t current_gfp_context(gfp_t flags)
  {
-   if (unlikely(current->flags &
+   unsigned int pflags = READ_ONCE(current->flags);


Why use READ_ONCE() here?


+   if (unlikely(pflags &
 (PF_MEMALLOC_NOIO | PF_MEMALLOC_NOFS | 
PF_MEMALLOC_NOCMA))) {
/*
 * NOIO implies both NOIO and NOFS and it is a weaker context
 * so always make sure it makes precedence
 */
-   if (current->flags & PF_MEMALLOC_NOIO)
+   if (pflags & PF_MEMALLOC_NOIO)
flags &= ~(__GFP_IO | __GFP_FS);
-   else if (current->flags & PF_MEMALLOC_NOFS)
+   else if (pflags & PF_MEMALLOC_NOFS)
flags &= ~__GFP_FS;
  #ifdef CONFIG_CMA
-   if (current->flags & PF_MEMALLOC_NOCMA)
+   if (pflags & PF_MEMALLOC_NOCMA)
flags &= ~__GFP_MOVABLE;
  #endif
}

[PATCH v5 04/17] PCI: endpoint: Make *_free_bar() to return error codes on failure

[Kishon Vijay Abraham I]

Modify pci_epc_get_next_free_bar() and pci_epc_get_first_free_bar() to
return error values if there are no free BARs available.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/functions/pci-epf-test.c |  2 ++
 drivers/pci/endpoint/pci-epc-core.c   | 12 ++--
 include/linux/pci-epc.h   |  8 
 include/linux/pci-epf.h   |  1 +
 4 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c 
b/drivers/pci/endpoint/functions/pci-epf-test.c
index e4e51d884553..7a1f3abfde48 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -834,6 +834,8 @@ static int pci_epf_test_bind(struct pci_epf *epf)
linkup_notifier = epc_features->linkup_notifier;
core_init_notifier = epc_features->core_init_notifier;
test_reg_bar = pci_epc_get_first_free_bar(epc_features);
+   if (test_reg_bar < 0)
+   return -EINVAL;
pci_epf_configure_bar(epf, epc_features);
}
 
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 1afe5d9afb0d..ea7e7465ce7a 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -90,8 +90,8 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
  * Invoke to get the first unreserved BAR that can be used by the endpoint
  * function. For any incorrect value in reserved_bar return '0'.
  */
-unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
-   *epc_features)
+enum pci_barno
+pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features)
 {
return pci_epc_get_next_free_bar(epc_features, BAR_0);
 }
@@ -105,13 +105,13 @@ EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
  * Invoke to get the next unreserved BAR starting from @bar that can be used
  * for endpoint function. For any incorrect value in reserved_bar return '0'.
  */
-unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
-  *epc_features, enum pci_barno bar)
+enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
+*epc_features, enum pci_barno bar)
 {
unsigned long free_bar;
 
if (!epc_features)
-   return 0;
+   return BAR_0;
 
/* If 'bar - 1' is a 64-bit BAR, move to the next BAR */
if ((epc_features->bar_fixed_64bit << 1) & 1 << bar)
@@ -126,7 +126,7 @@ unsigned int pci_epc_get_next_free_bar(const struct 
pci_epc_features
 
free_bar = find_next_zero_bit(&free_bar, 6, bar);
if (free_bar > 5)
-   return 0;
+   return NO_BAR;
 
return free_bar;
 }
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cfe9b427e6b7..88d311bad984 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -201,10 +201,10 @@ int pci_epc_start(struct pci_epc *epc);
 void pci_epc_stop(struct pci_epc *epc);
 const struct pci_epc_features *pci_epc_get_features(struct pci_epc *epc,
u8 func_no);
-unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
-   *epc_features);
-unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
-  *epc_features, enum pci_barno bar);
+enum pci_barno
+pci_epc_get_first_free_bar(const struct pci_epc_features *epc_features);
+enum pci_barno pci_epc_get_next_free_bar(const struct pci_epc_features
+*epc_features, enum pci_barno bar);
 struct pci_epc *pci_epc_get(const char *epc_name);
 void pci_epc_put(struct pci_epc *epc);
 
diff --git a/include/linux/pci-epf.h b/include/linux/pci-epf.h
index 6644ff3b0702..fa3aca43eb19 100644
--- a/include/linux/pci-epf.h
+++ b/include/linux/pci-epf.h
@@ -21,6 +21,7 @@ enum pci_notify_event {
 };
 
 enum pci_barno {
+   NO_BAR = -1,
BAR_0,
BAR_1,
BAR_2,
-- 
2.17.1

[PATCH v5 02/17] PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit BAR

[Kishon Vijay Abraham I]

pci_epc_get_first_free_bar() uses only "reserved_bar" member in
epc_features to get the first unreserved BAR. However if the
reserved BAR is also a 64-bit BAR, then the next BAR shouldn't be
returned (since 64-bit BAR uses two BARs).

Make pci_epc_get_first_free_bar() take into account 64 bit BAR while
returning the first free unreserved BAR.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index cadd3db0cbb0..25e57672e1a1 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -93,12 +93,20 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features)
 {
-   int free_bar;
+   unsigned long free_bar;
 
if (!epc_features)
return 0;
 
-   free_bar = ffz(epc_features->reserved_bar);
+   /* Find if the reserved BAR is also a 64-bit BAR */
+   free_bar = epc_features->reserved_bar & epc_features->bar_fixed_64bit;
+
+   /* Set the adjacent bit if the reserved BAR is also a 64-bit BAR */
+   free_bar <<= 1;
+   free_bar |= epc_features->reserved_bar;
+
+   /* Now find the free BAR */
+   free_bar = ffz(free_bar);
if (free_bar > 5)
return 0;
 
-- 
2.17.1

[PATCH v5 03/17] PCI: endpoint: Add helper API to get the 'next' unreserved BAR

[Kishon Vijay Abraham I]

Add an API to get the next unreserved BAR starting from a given BAR
number that can be used by the endpoint function.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/endpoint/pci-epc-core.c | 26 ++
 include/linux/pci-epc.h |  2 ++
 2 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index 25e57672e1a1..1afe5d9afb0d 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -87,17 +87,36 @@ EXPORT_SYMBOL_GPL(pci_epc_get);
  * pci_epc_get_first_free_bar() - helper to get first unreserved BAR
  * @epc_features: pci_epc_features structure that holds the reserved bar bitmap
  *
- * Invoke to get the first unreserved BAR that can be used for endpoint
+ * Invoke to get the first unreserved BAR that can be used by the endpoint
  * function. For any incorrect value in reserved_bar return '0'.
  */
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features)
+{
+   return pci_epc_get_next_free_bar(epc_features, BAR_0);
+}
+EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
+
+/**
+ * pci_epc_get_next_free_bar() - helper to get unreserved BAR starting from 
@bar
+ * @epc_features: pci_epc_features structure that holds the reserved bar bitmap
+ * @bar: the starting BAR number from where unreserved BAR should be searched
+ *
+ * Invoke to get the next unreserved BAR starting from @bar that can be used
+ * for endpoint function. For any incorrect value in reserved_bar return '0'.
+ */
+unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
+  *epc_features, enum pci_barno bar)
 {
unsigned long free_bar;
 
if (!epc_features)
return 0;
 
+   /* If 'bar - 1' is a 64-bit BAR, move to the next BAR */
+   if ((epc_features->bar_fixed_64bit << 1) & 1 << bar)
+   bar++;
+
/* Find if the reserved BAR is also a 64-bit BAR */
free_bar = epc_features->reserved_bar & epc_features->bar_fixed_64bit;
 
@@ -105,14 +124,13 @@ unsigned int pci_epc_get_first_free_bar(const struct 
pci_epc_features
free_bar <<= 1;
free_bar |= epc_features->reserved_bar;
 
-   /* Now find the free BAR */
-   free_bar = ffz(free_bar);
+   free_bar = find_next_zero_bit(&free_bar, 6, bar);
if (free_bar > 5)
return 0;
 
return free_bar;
 }
-EXPORT_SYMBOL_GPL(pci_epc_get_first_free_bar);
+EXPORT_SYMBOL_GPL(pci_epc_get_next_free_bar);
 
 /**
  * pci_epc_get_features() - get the features supported by EPC
diff --git a/include/linux/pci-epc.h b/include/linux/pci-epc.h
index cc66bec8be90..cfe9b427e6b7 100644
--- a/include/linux/pci-epc.h
+++ b/include/linux/pci-epc.h
@@ -203,6 +203,8 @@ const struct pci_epc_features *pci_epc_get_features(struct 
pci_epc *epc,
u8 func_no);
 unsigned int pci_epc_get_first_free_bar(const struct pci_epc_features
*epc_features);
+unsigned int pci_epc_get_next_free_bar(const struct pci_epc_features
+  *epc_features, enum pci_barno bar);
 struct pci_epc *pci_epc_get(const char *epc_name);
 void pci_epc_put(struct pci_epc *epc);
 
-- 
2.17.1

[PATCH v5 01/17] Documentation: PCI: Add specification for the *PCI NTB* function device

[Kishon Vijay Abraham I]

Add specification for the *PCI NTB* function device. The endpoint function
driver and the host PCI driver should be created based on this
specification.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/PCI/endpoint/index.rst  |   1 +
 .../PCI/endpoint/pci-ntb-function.rst | 351 ++
 2 files changed, 352 insertions(+)
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-function.rst

diff --git a/Documentation/PCI/endpoint/index.rst 
b/Documentation/PCI/endpoint/index.rst
index 4ca7439fbfc9..ef6861128506 100644
--- a/Documentation/PCI/endpoint/index.rst
+++ b/Documentation/PCI/endpoint/index.rst
@@ -11,5 +11,6 @@ PCI Endpoint Framework
pci-endpoint-cfs
pci-test-function
pci-test-howto
+   pci-ntb-function
 
function/binding/pci-test
diff --git a/Documentation/PCI/endpoint/pci-ntb-function.rst 
b/Documentation/PCI/endpoint/pci-ntb-function.rst
new file mode 100644
index ..f7246c812801
--- /dev/null
+++ b/Documentation/PCI/endpoint/pci-ntb-function.rst
@@ -0,0 +1,351 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+PCI NTB Function
+=
+
+:Author: Kishon Vijay Abraham I 
+
+PCI Non Transparent Bridges (NTB) allow two host systems to communicate
+with each other by exposing each host as a device to the other host.
+NTBs typically support the ability to generate interrupts on the remote
+machine, expose memory ranges as BARs and perform DMA.  They also support
+scratchpads which are areas of memory within the NTB that are accessible
+from both machines.
+
+PCI NTB Function allows two different systems (or hosts) to communicate
+with each other by configurig the endpoint instances in such a way that
+transactions from one system is routed to the other system.
+
+In the below diagram, PCI NTB function configures the SoC with multiple
+PCIe Endpoint (EP) instances in such a way that transaction from one EP
+controller is routed to the other EP controller. Once PCI NTB function
+configures the SoC with multiple EP instances, HOST1 and HOST2 can
+communicate with each other using SoC as a bridge.
+
+.. code-block:: text
+
++-+   +-+
+| |   | |
+|HOST1|   |HOST2|
+| |   | |
++--^--+   +--^--+
+   | |
+   | |
+ +-|-|-+
+ |  +--v--+   +--v--+  |
+ |  | |   | |  |
+ |  | EP  |   | EP  |  |
+ |  | CONTROLLER1 |   | CONTROLLER2 |  |
+ |  | <---> |  |
+ |  | |   | |  |
+ |  | |   | |  |
+ |  | |  SoC With Multiple EP Instances   | |  |
+ |  | |  (Configured using NTB Function)  | |  |
+ |  +-+   +-+  |
+ +-+
+
+Constructs used for Implementing NTB
+
+
+   1) Config Region
+   2) Self Scratchpad Registers
+   3) Peer Scratchpad Registers
+   4) Doorbell Registers
+   5) Memory Window
+
+
+Config Region:
+--
+
+Config Region is a construct that is specific to NTB implemented using NTB
+Endpoint Function Driver. The host and endpoint side NTB function driver will
+exchange information with each other using this region. Config Region has
+Control/Status Registers for configuring the Endpoint Controller. Host can
+write into this region for configuring the outbound ATU and to indicate the
+link status. Endpoint can indicate the status of commands issued be host in
+this region. Endpoint can also indicate the scratchpad offset, number of
+memory windows to the host using this region.
+
+The format of Config Region is given below. Each of the fields here are 32
+bits.
+
+.. code-block:: text
+
+   ++
+   | COMMAND|
+   ++
+   | ARGUMENT   |
+   ++
+   | STATUS |
+   ++
+   | TOPOLOGY   |
+   ++
+   |ADDRESS (LOWER 32)  |
+   ++
+   |ADDRESS (UPPER 32)  |
+   ++
+   |   SIZE |
+   +--

[PATCH v5 00/17] Implement NTB Controller using multiple PCI EP

[Kishon Vijay Abraham I]

This series is about implementing SW defined NTB using
multiple endpoint instances. This series has been tested using
2 endpoint instances in J7 connected to J7 board on one end and DRA7 board
on the other end. However there is nothing platform specific for the NTB
functionality.

This was presented in Linux Plumbers Conference. The presentation
can be found @ [1]

RFC patch series can be found @ [2]
v1 patch series can be found @ [3]
v2 patch series can be found @ [4]
v3 patch series can be found @ [5]
v4 patch series can be found @ [6]

Changes from v3:
1) Fixed Documentation edits suggested by Randy Dunlap 

Changes from v2:
1) Add support for the user to create sub-directory of 'EPF Device'
   directory (for endpoint function specific configuration using
   configfs).
2) Add documentation for NTB specific attributes in configfs
3) Check for PCI_CLASS_MEMORY_RAM (PCIe class) before binding ntb_hw_epf
   driver
4) Other documentation fixes

Changes from v1:
1) As per Rob's comment, removed support for creating NTB function
   device from DT
2) Add support to create NTB EPF device using configfs (added support in
   configfs to associate primary and secondary EPC with EPF.

Changes from RFC:
1) Converted the DT binding patches to YAML schema and merged the
   DT binding patches together
2) NTB documentation is converted to .rst
3) One HOST can now interrupt the other HOST using MSI-X interrupts
4) Added support for teardown of memory window and doorbell
   configuration
5) Add support to provide support 64-bit memory window size from
   DT

[1] -> 
https://www.linuxplumbersconf.org/event/4/contributions/395/attachments/284/481/Implementing_NTB_Controller_Using_PCIe_Endpoint_-_final.pdf
[2] -> http://lore.kernel.org/r/20190926112933.8922-1-kis...@ti.com
[3] -> http://lore.kernel.org/r/20200514145927.17555-1-kis...@ti.com
[4] -> http://lore.kernel.org/r/20200611130525.22746-1-kis...@ti.com
[5] -> http://lore.kernel.org/r/20200904075052.8911-1-kis...@ti.com
[6] -> http://lore.kernel.org/r/20200915042110.3015-1-kis...@ti.com

Kishon Vijay Abraham I (17):
  Documentation: PCI: Add specification for the *PCI NTB* function
device
  PCI: endpoint: Make *_get_first_free_bar() take into account 64 bit
BAR
  PCI: endpoint: Add helper API to get the 'next' unreserved BAR
  PCI: endpoint: Make *_free_bar() to return error codes on failure
  PCI: endpoint: Remove unused pci_epf_match_device()
  PCI: endpoint: Add support to associate secondary EPC with EPF
  PCI: endpoint: Add support in configfs to associate two EPCs with EPF
  PCI: endpoint: Add pci_epc_ops to map MSI irq
  PCI: endpoint: Add pci_epf_ops for epf drivers to expose function
specific attrs
  PCI: endpoint: Allow user to create sub-directory of 'EPF Device'
directory
  PCI: cadence: Implement ->msi_map_irq() ops
  PCI: endpoint: Add EP function driver to provide NTB functionality
  PCI: Add TI J721E device to pci ids
  NTB: Add support for EPF PCI-Express Non-Transparent Bridge
  NTB: tool: Enable the NTB/PCIe link on the local or remote side of
bridge
  Documentation: PCI: Add configfs binding documentation for pci-ntb
endpoint function
  Documentation: PCI: Add userguide for PCI endpoint NTB function

 .../PCI/endpoint/function/binding/pci-ntb.rst |   38 +
 Documentation/PCI/endpoint/index.rst  |3 +
 .../PCI/endpoint/pci-endpoint-cfs.rst |   10 +
 .../PCI/endpoint/pci-ntb-function.rst |  351 +++
 Documentation/PCI/endpoint/pci-ntb-howto.rst  |  160 ++
 drivers/misc/pci_endpoint_test.c  |1 -
 drivers/ntb/hw/Kconfig|1 +
 drivers/ntb/hw/Makefile   |1 +
 drivers/ntb/hw/epf/Kconfig|6 +
 drivers/ntb/hw/epf/Makefile   |1 +
 drivers/ntb/hw/epf/ntb_hw_epf.c   |  751 ++
 drivers/ntb/test/ntb_tool.c   |1 +
 .../pci/controller/cadence/pcie-cadence-ep.c  |   50 +
 drivers/pci/endpoint/functions/Kconfig|   12 +
 drivers/pci/endpoint/functions/Makefile   |1 +
 drivers/pci/endpoint/functions/pci-epf-ntb.c  | 2106 +
 drivers/pci/endpoint/functions/pci-epf-test.c |   13 +-
 drivers/pci/endpoint/pci-ep-cfs.c |  176 +-
 drivers/pci/endpoint/pci-epc-core.c   |  131 +-
 drivers/pci/endpoint/pci-epf-core.c   |  105 +-
 include/linux/pci-epc.h   |   38 +-
 include/linux/pci-epf.h   |   28 +-
 include/linux/pci_ids.h   |1 +
 23 files changed, 3918 insertions(+), 67 deletions(-)
 create mode 100644 Documentation/PCI/endpoint/function/binding/pci-ntb.rst
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-function.rst
 create mode 100644 Documentation/PCI/endpoint/pci-ntb-howto.rst
 create mode 100644 drivers/ntb/hw/epf/Kconfig
 create mode 100644 drivers/ntb/hw/epf/Makefile
 create mode 100644 drivers/ntb/hw/epf/ntb_hw_epf.c
 create mode 100644 drivers/pci/

Re: [RFC PATCH] Add bridge driver to connect sensors to CIO2 device via software nodes on ACPI platforms

[Sakari Ailus]

Hi Dan,

On Thu, Sep 17, 2020 at 01:49:41PM +0300, Dan Carpenter wrote:
> On Thu, Sep 17, 2020 at 01:33:43PM +0300, Sakari Ailus wrote:
> > > +static int connect_supported_devices(void)
> > > +{
> > > + struct acpi_device *adev;
> > > + struct device *dev;
> > > + struct sensor_bios_data ssdb;
> > > + struct sensor *sensor;
> > > + struct property_entry *sensor_props;
> > > + struct property_entry *cio2_props;
> > > + struct fwnode_handle *fwnode;
> > > + struct software_node *nodes;
> > > + struct v4l2_subdev *sd;
> > > + int i, ret;
> > 
> > unsigned int i
> > 
> 
> Why?
> 
> For list iterators then "int i;" is best...  For sizes then unsigned is
> sometimes best.  Or if it's part of the hardware spec or network spec
> unsigned is best.  Otherwise unsigned variables cause a ton of bugs.
> They're not as intuitive as signed variables.  Imagine if there is an
> error in this loop and you want to unwind.  With a signed variable you
> can do:
> 
>   while (--i >= 0)
>   cleanup(&bridge.sensors[i]);
> 
> There are very few times where raising the type maximum from 2 billion
> to 4 billion fixes anything.

There's simply no need for the negative integers here. Sizes (as it's a
size here) are unsigned, too, so you'd be comparing signed and unsigned
numbers later in the function.

-- 
Regards,

Sakari Ailus

sound/soc/meson/t9015.c:315:34: warning: unused variable 't9015_ids'

[kernel test robot]

Hi Jerome,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   10b82d5176488acee2820e5a2cf0f2ec5c3488b6
commit: 33901f5b9b16d212ee58865e9e8e80fc813f12da ASoC: meson: add t9015 
internal DAC driver
date:   7 months ago
config: x86_64-randconfig-a011-20200918 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
0ff28fa6a75617d61b1aeea77463d6a1684c3c89)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git checkout 33901f5b9b16d212ee58865e9e8e80fc813f12da
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> sound/soc/meson/t9015.c:315:34: warning: unused variable 't9015_ids' 
>> [-Wunused-const-variable]
   static const struct of_device_id t9015_ids[] = {
^
   1 warning generated.

# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=33901f5b9b16d212ee58865e9e8e80fc813f12da
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 33901f5b9b16d212ee58865e9e8e80fc813f12da
vim +/t9015_ids +315 sound/soc/meson/t9015.c

   314  
 > 315  static const struct of_device_id t9015_ids[] = {
   316  { .compatible = "amlogic,t9015", },
   317  { }
   318  };
   319  MODULE_DEVICE_TABLE(of, t9015_ids);
   320  

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


.config.gz
Description: application/gzip

Re: [RFC PATCH V3 12/21] mmc: sdhci: UHS-II support, add hooks for additional operations

[AKASHI Takahiro]

Adrian, Ben,

Regarding _set_ios() function,

On Fri, Aug 21, 2020 at 05:08:32PM +0300, Adrian Hunter wrote:
> On 10/07/20 2:10 pm, Ben Chuang wrote:
> > From: Ben Chuang 
> > 
> > In this commit, UHS-II related operations will be called via a function
> > pointer array, sdhci_uhs2_ops, in order to make UHS-II support as
> > a kernel module.
> > This array will be initialized only if CONFIG_MMC_SDHCI_UHS2 is enabled
> > and when the UHS-II module is loaded. Otherwise, all the functions
> > stay void.
> > 
> > Signed-off-by: Ben Chuang 
> > Signed-off-by: AKASHI Takahiro 

  (snip)

> > @@ -2261,6 +2324,7 @@ void sdhci_set_ios(struct mmc_host *mmc, struct 
> > mmc_ios *ios)
> >  {
> > struct sdhci_host *host = mmc_priv(mmc);
> > u8 ctrl;
> > +   u16 ctrl_2;
> >  
> > if (ios->power_mode == MMC_POWER_UNDEFINED)
> > return;
> > @@ -2287,6 +2351,10 @@ void sdhci_set_ios(struct mmc_host *mmc, struct 
> > mmc_ios *ios)
> > sdhci_enable_preset_value(host, false);
> >  
> > if (!ios->clock || ios->clock != host->clock) {
> > +   if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> > +   ios->timing == MMC_TIMING_UHS2)
> > +   host->timing = ios->timing;
> > +
> > host->ops->set_clock(host, ios->clock);
> > host->clock = ios->clock;
> >  
> > @@ -2308,6 +2376,18 @@ void sdhci_set_ios(struct mmc_host *mmc, struct 
> > mmc_ios *ios)
> > else
> > sdhci_set_power(host, ios->power_mode, ios->vdd);
> >  
> > +   /* 4.0 host support */
> > +   if (host->version >= SDHCI_SPEC_400) {
> > +   /* UHS2 Support */
> > +   if (IS_ENABLED(CONFIG_MMC_SDHCI_UHS2) &&
> > +   host->mmc->flags & MMC_UHS2_SUPPORT &&
> > +   host->mmc->caps & MMC_CAP_UHS2) {
> > +   if (sdhci_uhs2_ops.do_set_ios)
> > +   sdhci_uhs2_ops.do_set_ios(host, ios);
> > +   return;
> > +   }
> > +   }
> > +
> 
> Please look at using existing callbacks instead, maybe creating 
> uhs2_set_ios(), uhs2_set_clock(), uhs2_set_power()

I think that we will create uhs2_set_ios() (and uhs2_set_power()
as we discussed on patch#15/21), but not uhs_set_clock().

Since we have a hook only in struct mmc_host_ops, but not in struct
sdhci_ops, all the drivers who want to support UHS-II need to
set host->mmc_host_ops->set_ios to sdhci_uhs2_set_ios explicitly
in their own init (or probe) function.
(Again, sdhci_uhs2_set_ios() seems to be generic though.)

Is this okay for you?
-> Adrian

During refactoring the code, I found that sdhci_set_power() is called
twice in sdhci_set_ios():
sdhci_set_ios(host, power_mode, vdd1, -1); in sdhci_set_ios(), and
sdhci_set_ios(host, power_mode, vdd1, vdd2) in ush2_do_set_ios()

Can you please confirm that those are redundant?
-> Ben

I also wonder why we need spin locks in uhs2_do_set_ios() while
not in sdhci_set_ios().

-> Ben

-Takahiro Akashi

Re: [PATCH AUTOSEL 5.4 101/330] powerpc/powernv/ioda: Fix ref count for devices with their own PE

[Frederic Barrat]

Le 18/09/2020 à 03:57, Sasha Levin a écrit :

From: Frederic Barrat 

[ Upstream commit 05dd7da76986937fb288b4213b1fa10dbe0d1b33 ]



This patch is not desirable for stable, for 5.4 and 4.19 (it was already 
flagged by autosel back in April. Not sure why it's showing again now)


  Fred



The pci_dn structure used to store a pointer to the struct pci_dev, so
taking a reference on the device was required. However, the pci_dev
pointer was later removed from the pci_dn structure, but the reference
was kept for the npu device.
See commit 902bdc57451c ("powerpc/powernv/idoa: Remove unnecessary
pcidev from pci_dn").

We don't need to take a reference on the device when assigning the PE
as the struct pnv_ioda_pe is cleaned up at the same time as
the (physical) device is released. Doing so prevents the device from
being released, which is a problem for opencapi devices, since we want
to be able to remove them through PCI hotplug.

Now the ugly part: nvlink npu devices are not meant to be
released. Because of the above, we've always leaked a reference and
simply removing it now is dangerous and would likely require more
work. There's currently no release device callback for nvlink devices
for example. So to be safe, this patch leaks a reference on the npu
device, but only for nvlink and not opencapi.

Signed-off-by: Frederic Barrat 
Reviewed-by: Andrew Donnellan 
Signed-off-by: Michael Ellerman 
Link: https://lore.kernel.org/r/20191121134918.7155-2-fbar...@linux.ibm.com
Signed-off-by: Sasha Levin 
---
  arch/powerpc/platforms/powernv/pci-ioda.c | 19 ---
  1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 058223233088e..e9cda7e316a50 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1062,14 +1062,13 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
return NULL;
}
  
-	/* NOTE: We get only one ref to the pci_dev for the pdn, not for the

-* pointer in the PE data structure, both should be destroyed at the
-* same time. However, this needs to be looked at more closely again
-* once we actually start removing things (Hotplug, SR-IOV, ...)
+   /* NOTE: We don't get a reference for the pointer in the PE
+* data structure, both the device and PE structures should be
+* destroyed at the same time. However, removing nvlink
+* devices will need some work.
 *
 * At some point we want to remove the PDN completely anyways
 */
-   pci_dev_get(dev);
pdn->pe_number = pe->pe_number;
pe->flags = PNV_IODA_PE_DEV;
pe->pdev = dev;
@@ -1084,7 +1083,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_dev_PE(struct 
pci_dev *dev)
pnv_ioda_free_pe(pe);
pdn->pe_number = IODA_INVALID_PE;
pe->pdev = NULL;
-   pci_dev_put(dev);
return NULL;
}
  
@@ -1205,6 +1203,14 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct pci_dev *npu_pdev)

struct pci_controller *hose = pci_bus_to_host(npu_pdev->bus);
struct pnv_phb *phb = hose->private_data;
  
+	/*

+* Intentionally leak a reference on the npu device (for
+* nvlink only; this is not an opencapi path) to make sure it
+* never goes away, as it's been the case all along and some
+* work is needed otherwise.
+*/
+   pci_dev_get(npu_pdev);
+
/*
 * Due to a hardware errata PE#0 on the NPU is reserved for
 * error handling. This means we only have three PEs remaining
@@ -1228,7 +1234,6 @@ static struct pnv_ioda_pe *pnv_ioda_setup_npu_PE(struct 
pci_dev *npu_pdev)
 */
dev_info(&npu_pdev->dev,
"Associating to existing PE %x\n", pe_num);
-   pci_dev_get(npu_pdev);
npu_pdn = pci_get_pdn(npu_pdev);
rid = npu_pdev->bus->number << 8 | npu_pdn->devfn;
npu_pdn->pe_number = pe_num;

Re: [linux-next PATCH] rapidio: Fix error handling path

[John Hubbard]

On 9/17/20 7:21 PM, Souptick Joarder wrote:

On Thu, Sep 17, 2020 at 11:17 PM John Hubbard  wrote:

...

I sort of feel like returning partial successes is not working.  We
could easily make a wrapper which either pins everything or it returns
an error code.


Yes we could. And I have the same feeling about this API. It's generated a
remarkable amount of bug fixes, several of which ended up being partial or
wrong in themselves. And mostly this is due to the complicated tristate
return code: instead of 0 or -ERRNO, it also can return "N pages that is
less than what you requested", and there are no standard helpers in the kernel
to make that easier to deal with


There was some discussion on removing return value 0 from one of the
gup variants [1].
I think it might be partially relevant to the current discussion.

[1] https://patchwork.kernel.org/patch/11529795/



Yes, although as I mentioned above, I'm thinking of a 0 or -ERRNO return value,
and not even return nr_pages at all.

But in any case, as a practical matter, I'm not sure if it's a good idea to
actually change all the callsites, or not. If we just fix the remaining buggy
callers, maybe that's better than the churn associated with another API change.

On the other-other hand, there does seem to be more churn coming anyway, with
talk of actually doing a [get|pin]_user_bvec(), for example. So maybe it's 
better
to head off the coming mess.

This is something that should be discussed on linux-mm.





I guess the question is are there drivers which will keep working (or limp
along?) on partial pins?  A quick search of a driver I thought did this does
not apparently any more...  So it sounds good to me from 30,000 feet!  :-D


It sounds good to me too--and from just a *few hundred feet* (having touched 
most
of the call sites at some point)! haha :)

I think the wrapper should be short-term, though, just until all the callers
are converted to the simpler API. Then change the core gup/pup calls to the 
simpler
API. There are more than enough gup/pup API entry points as it is, that's for 
sure.


thanks,
--
John Hubbard
NVIDIA


thanks,
--
John Hubbard
NVIDIA

Re: [PATCH] batman-adv: Fix orig node refcnt leak when creating neigh node

[Sven Eckelmann]

On Friday, 18 September 2020 05:03:19 CEST Xiyu Yang wrote:
> batadv_neigh_node_create() is used to create a neigh node object, whose
> fields will be initialized with the specific object. When a new
> reference of the specific object is created during the initialization,
> its refcount should be increased.
> 
> However, when "neigh_node" object initializes its orig_node field with
> the "orig_node" object, the function forgets to hold the refcount of the
> "orig_node", causing a potential refcount leak and use-after-free issue
> for the reason that the object can be freed in other places.
> 
> Fix this issue by increasing the refcount of orig_node object during the
> initialization and adding corresponding batadv_orig_node_put() in
> batadv_neigh_node_release().


I will most likely not add this patch because I have concerns that this would 
need an active garbage collector to fix the reference counter loop.

Please check batadv_neigh_node::orig_node (whose reference counter you've just 
incremented) and batadv_orig_node::neigh_list (with batadv_neigh_node). And at 
the same time the batadv_neigh_node_release and batadv_orig_node_release. So 
the originator will only free the reference (and thus potentially call 
batadv_neigh_node_release) when its own reference counter is zero. But it 
cannot become zero because the neigh_node is holding a reference to this 
originator.

Kind regards,
Sven


signature.asc
Description: This is a digitally signed message part.

[PATCH v2 2/3] dmaengine: add peripheral configuration

[Vinod Koul]

Some complex dmaengine controllers have capability to program the
peripheral device, so pass on the peripheral configuration as part of
dma_slave_config

Signed-off-by: Vinod Koul 
---
 include/linux/dmaengine.h | 90 +++
 1 file changed, 90 insertions(+)

diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
index 6fbd5c99e30c..89e0fe8e0b1c 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -380,6 +380,93 @@ enum dma_slave_buswidth {
DMA_SLAVE_BUSWIDTH_64_BYTES = 64,
 };
 
+/**
+ * enum spi_transfer_cmd - spi transfer commands
+ */
+enum spi_transfer_cmd {
+   SPI_TX = 1,
+   SPI_RX,
+   SPI_DUPLEX,
+};
+
+/**
+ * struct dmaengine_spi_config - spi config for peripheral
+ *
+ * @loopback_en: spi loopback enable when set
+ * @clock_pol: clock polarity
+ * @data_pol: data polarity
+ * @pack_en: process tx/rx buffers as packed
+ * @word_len: spi word length
+ * @clk_div: source clock divider
+ * @clk_src: serial clock
+ * @cmd: spi cmd
+ * @cs: chip select toggle
+ */
+struct dmaengine_spi_config {
+   u8 loopback_en;
+   u8 clock_pol;
+   u8 data_pol;
+   u8 pack_en;
+   u8 word_len;
+   u32 clk_div;
+   u32 clk_src;
+   u8 fragmentation;
+   enum spi_transfer_cmd cmd;
+   u8 cs;
+};
+
+enum i2c_op {
+   I2C_WRITE = 1,
+   I2C_READ,
+};
+
+/**
+ * struct dmaengine_i2c_config - i2c config for peripheral
+ *
+ * @pack_enable: process tx/rx buffers as packed
+ * @cycle_count: clock cycles to be sent
+ * @high_count: high period of clock
+ * @low_count: low period of clock
+ * @clk_div: source clock divider
+ * @addr: i2c bus address
+ * @stretch: stretch the clock at eot
+ * @op: i2c cmd
+ */
+struct dmaengine_i2c_config {
+   u8 pack_enable;
+   u8 cycle_count;
+   u8 high_count;
+   u8 low_count;
+   u16 clk_div;
+   u8 addr;
+   u8 stretch;
+   enum i2c_op op;
+};
+
+enum dmaengine_peripheral {
+   DMAENGINE_PERIPHERAL_SPI = 1,
+   DMAENGINE_PERIPHERAL_UART = 2,
+   DMAENGINE_PERIPHERAL_I2C = 3,
+   DMAENGINE_PERIPHERAL_LAST = DMAENGINE_PERIPHERAL_I2C,
+};
+
+/**
+ * struct dmaengine_peripheral_config - peripheral configuration for
+ * dmaengine peripherals
+ *
+ * @peripheral: type of peripheral to DMA to/from
+ * @set_config: set peripheral config
+ * @rx_len: receive length for buffer
+ * @spi: peripheral config for spi
+ * @i2c: peripheral config for i2c
+ */
+struct dmaengine_peripheral_config {
+   enum dmaengine_peripheral peripheral;
+   u8 set_config;
+   u32 rx_len;
+   struct dmaengine_spi_config spi;
+   struct dmaengine_i2c_config i2c;
+};
 /**
  * struct dma_slave_config - dma slave channel runtime config
  * @direction: whether the data shall go in or out on this slave
@@ -418,6 +505,8 @@ enum dma_slave_buswidth {
  * @slave_id: Slave requester id. Only valid for slave channels. The dma
  * slave peripheral will have unique id as dma requester which need to be
  * pass as slave config.
+ * @peripheral: peripheral configuration for programming peripheral for
+ * dmaengine transfer
  *
  * This struct is passed in as configuration data to a DMA engine
  * in order to set up a certain channel for DMA transport at runtime.
@@ -443,6 +532,7 @@ struct dma_slave_config {
u32 dst_port_window_size;
bool device_fc;
unsigned int slave_id;
+   struct dmaengine_peripheral_config *peripheral;
 };
 
 /**
-- 
2.26.2

[PATCH v2 1/3] dt-bindings: dmaengine: Document qcom,gpi dma binding

[Vinod Koul]

Add devicetree binding documentation for GPI DMA controller
implemented on Qualcomm SoCs

Signed-off-by: Vinod Koul 
---
 .../devicetree/bindings/dma/qcom,gpi.yaml | 86 +++
 include/dt-bindings/dma/qcom-gpi.h| 11 +++
 2 files changed, 97 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom,gpi.yaml
 create mode 100644 include/dt-bindings/dma/qcom-gpi.h

diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml 
b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
new file mode 100644
index ..82f404bc8745
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml
@@ -0,0 +1,86 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/qcom,gpi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies Inc GPI DMA controller
+
+maintainers:
+  - Vinod Koul 
+
+description: |
+  QCOM GPI DMA controller provides DMA capabilities for
+  peripheral buses such as I2C, UART, and SPI.
+
+allOf:
+  - $ref: "dma-controller.yaml#"
+
+properties:
+  compatible:
+enum:
+  - qcom,gpi-dma
+
+  reg:
+maxItems: 1
+
+  interrupts:
+description:
+  Interrupt lines for each GPII instance
+maxItems: 13
+
+  "#dma-cells":
+const: 3
+description: >
+  DMA clients must use the format described in dma.txt, giving a phandle
+  to the DMA controller plus the following 3 integer cells:
+  - channel: if set to 0x, any available channel will be allocated
+for the client. Otherwise, the exact channel specified will be used.
+  - seid: serial id of the client as defined in the SoC documentation.
+  - client: type of the client as defined in dt-bindings/dma/qcom-gpi.h
+
+  iommus:
+maxItems: 1
+
+  dma-channels:
+maxItems: 1
+
+  dma-channel-mask:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - interrupts
+  - "#dma-cells"
+  - iommus
+  - dma-channels
+  - dma-channel-mask
+
+examples:
+  - |
+#include 
+#include 
+gpi_dma0: dma-controller@80 {
+compatible = "qcom,gpi-dma";
+#dma-cells = <3>;
+reg = <0x0080 0x6>;
+iommus = <&apps_smmu 0x0016 0x0>;
+dma-channels = <13>;
+dma-channel-mask = <0xfa>;
+interrupts = ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ,
+ ;
+};
+
+...
diff --git a/include/dt-bindings/dma/qcom-gpi.h 
b/include/dt-bindings/dma/qcom-gpi.h
new file mode 100644
index ..71f79eb7614c
--- /dev/null
+++ b/include/dt-bindings/dma/qcom-gpi.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* Copyright (c) 2020, Linaro Ltd.  */
+
+#ifndef __DT_BINDINGS_DMA_QCOM_GPI_H__
+#define __DT_BINDINGS_DMA_QCOM_GPI_H__
+
+#define QCOM_GPI_SPI   1
+#define QCOM_GPI_UART  2
+#define QCOM_GPI_I2C   3
+
+#endif /* __DT_BINDINGS_DMA_QCOM_GPI_H__ */
-- 
2.26.2

[PATCH v2 0/3] dmaengine: Add support for QCOM GSI dma controller

[Vinod Koul]

This series adds support for Qcom GSI dma controller found on Qualcomm SoCs.
This controller can program the peripheral configuration so we add
additional parameters in dma_slave_config for configuring the peripherals
like spi and i2c.

Changes in v2:
 - Update the binding and drop qcom specific properties
 - Move peripheral configuration as a pointer
 - Move submit queue for transactions to issue_pending

Vinod Koul (3):
  dt-bindings: dmaengine: Document qcom,gpi dma binding
  dmaengine: add peripheral configuration
  dmaengine: qcom: Add GPI dma driver

 .../devicetree/bindings/dma/qcom,gpi.yaml |   86 +
 drivers/dma/qcom/Kconfig  |   12 +
 drivers/dma/qcom/Makefile |1 +
 drivers/dma/qcom/gpi.c| 2280 +
 include/dt-bindings/dma/qcom-gpi.h|   11 +
 include/linux/dmaengine.h |   90 +
 6 files changed, 2480 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/qcom,gpi.yaml
 create mode 100644 drivers/dma/qcom/gpi.c
 create mode 100644 include/dt-bindings/dma/qcom-gpi.h

-- 
2.26.2

Re: [PATCH v14 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings

[Punit Agrawal]

Hi Ben,

One query below -

Ben Levinsky  writes:

> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
>
> Signed-off-by: Jason Wu 
> Signed-off-by: Wendy Liang 
> Signed-off-by: Michal Simek 
>
> Signed-off-by: Ben Levinsky 
> ---

[...]

>  .../xilinx,zynqmp-r5-remoteproc.yaml  | 119 ++
>  1 file changed, 119 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
>
> diff --git 
> a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
>  
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
> new file mode 100644
> index ..cd2406b4dc24
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
> @@ -0,0 +1,119 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#";
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#";
> +
> +title: Xilinx R5 remote processor controller bindings
> +
> +description:
> +  This document defines the binding for the remoteproc component that loads 
> and
> +  boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> +
> +  Note that the Linux has global addressing view of the R5-related memory 
> (TCM)
> +  so the absolute address ranges are provided in TCM reg's.
> +maintainers:
> +  - Ed Mooring 
> +  - Ben Levinsky 
> +
> +properties:
> +  compatible:
> +const: "xlnx,zynqmp-r5-remoteproc-1.0"
> +
> +  lockstep-mode:
> +description:
> +  R5 core configuration (split is 0 or lock-step and 1)
> +maxItems: 1

Looking at the driver, it seems that it is possible to set the R5s to
operate in split or lock-step mode dynamically.

If so, the device tree shouldn't really contain this property. Wouldn't
it be better to give the users flexibility to choose the mode at run
time?

Thanks,
Punit

> +
> +  interrupts:
> +description:
> +  Interrupt mapping for remoteproc IPI. It is required if the
> +  user uses the remoteproc driver with the RPMsg kernel driver.
> +maxItems: 6
> +
> +  memory-region:
> +description:
> +  collection of memory carveouts used for elf-loading and inter-processor
> +  communication.
> +maxItems: 4
> +minItems: 4
> +  meta-memory-regions:
> +description:
> +  collection of memories that are not present in the top level memory
> +  nodes' mapping. For example, R5s' TCM banks. These banks are needed
> +  for R5 firmware meta data such as the R5 firmware's heap and stack
> +  pnode-id:
> +maxItems: 1
> +  mboxes:
> +maxItems: 2
> +  mbox-names:
> +maxItems: 2
> +
> +examples:
> +  - |
> + reserved-memory {
> +  #address-cells = <1>;
> +  #size-cells = <1>;
> +  ranges;
> +  elf_load: rproc@3ed00 {
> +   no-map;
> +   reg = <0x3ed0 0x4>;
> +  };
> +
> +  rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
> +   no-map;
> +   reg = <0x3ed4 0x4000>;
> +  };
> +  rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
> +   no-map;
> +   reg = <0x3ed44000 0x4000>;
> +  };
> +  rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
> +   no-map;
> +   reg = <0x3ed48000 0x10>;
> +  };
> +
> + };
> +
> + /*
> +  * Below nodes are required if using TCM to load R5 firmware
> +  * if not, then either do not provide nodes are label as disabled in
> +  * status property
> +  */
> + tcm0a: tcm_0a@ffe0 {
> + reg = <0xffe0 0x1>;
> + pnode-id = <0xf>;
> + no-map;
> + status = "okay";
> + phandle = <0x40>;
> + compatible = "xlnx,tcm";
> + };
> + tcm0b: tcm_1a@ffe2 {
> + reg = <0xffe2 0x1>;
> + pnode-id = <0x10>;
> + no-map;
> + status = "okay";
> + compatible = "xlnx,tcm";
> + phandle = <0x41>;
> + };
> +
> + rpu {
> +  compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> +  #address-cells = <1>;
> +  #size-cells = <1>;
> +  ranges;
> +  lockstep-mode = <1>;
> +  r5_0 {
> +   ranges;
> +   #address-cells = <1>;
> +   #size-cells = <1>;
> +   memory-region = <&elf_load>,
> +   <&rpu0vdev0vring0>,
> +   <&rpu0vdev0vring1>,
> +   <&rpu0vdev0buffer>;
> +   meta-memory-regions = <&tcm_0a>, <&tcm_0b>;
> +   pnode-id = <0x7>;
> +  };
> + };
> +
> +...

Re: [PATCH -next] ide: Fix symbol undeclared warnings

[Michael Ellerman]

David Miller  writes:
> From: Michael Ellerman 
> Date: Thu, 17 Sep 2020 22:01:00 +1000
>
>> Wang Wensheng  writes:
>>> Build the object file with `C=2` and get the following warnings:
>>> make allmodconfig ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu-
>>> make C=2 drivers/ide/pmac.o ARCH=powerpc64
>>> CROSS_COMPILE=powerpc64-linux-gnu-
>>>
>>> drivers/ide/pmac.c:228:23: warning: symbol 'mdma_timings_33' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:241:23: warning: symbol 'mdma_timings_33k' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:254:23: warning: symbol 'mdma_timings_66' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:272:3: warning: symbol 'kl66_udma_timings' was not
>>> declared. Should it be static?
>>> drivers/ide/pmac.c:1418:12: warning: symbol 'pmac_ide_probe' was not
>>> declared. Should it be static?
>>>
>>> Signed-off-by: Wang Wensheng 
>>> ---
>>>  drivers/ide/pmac.c | 10 +-
>>>  1 file changed, 5 insertions(+), 5 deletions(-)
>> 
>> TIL davem maintains IDE?
>> 
>> But I suspect he isn't that interested in this powerpc only driver, so
>> I'll grab this.
>
> I did have it in my queue, but if you want to take it that's fine too :)

That's OK, if you've got it already you take it. Thanks.

cheers

Re: [PATCH AUTOSEL 4.9 23/90] efi/arm: Defer probe of PCIe backed efifb on DT systems

[Ard Biesheuvel]

On Fri, 18 Sep 2020 at 05:15, Sasha Levin  wrote:
>
> From: Ard Biesheuvel 
>
> [ Upstream commit 64c8a0cd0a535891d5905c3a1651150f0f141439 ]
>
> The new of_devlink support breaks PCIe probing on ARM platforms booting
> via UEFI if the firmware exposes a EFI framebuffer that is backed by a
> PCI device. The reason is that the probing order gets reversed,
> resulting in a resource conflict on the framebuffer memory window when
> the PCIe probes last, causing it to give up entirely.
>
> Given that we rely on PCI quirks to deal with EFI framebuffers that get
> moved around in memory, we cannot simply drop the memory reservation, so
> instead, let's use the device link infrastructure to register this
> dependency, and force the probing to occur in the expected order.
>
> Co-developed-by: Saravana Kannan 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Saravana Kannan 
> Signed-off-by: Ard Biesheuvel 
> Signed-off-by: Ingo Molnar 
> Link: https://lore.kernel.org/r/20200113172245.27925-9-a...@kernel.org
> Signed-off-by: Sasha Levin 

Same question as the previous time you proposed this patch for stable:
is the of_devlink framework being backported in its entirety? If not,
this patch does not belong in -stable.


> ---
>  drivers/firmware/efi/arm-init.c | 107 ++--
>  1 file changed, 103 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index 8ee91777abce7..e4ddd6e6edb31 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -14,10 +14,12 @@
>  #define pr_fmt(fmt)"efi: " fmt
>
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -262,15 +264,112 @@ void __init efi_init(void)
> efi_memmap_unmap();
>  }
>
> +static bool efifb_overlaps_pci_range(const struct of_pci_range *range)
> +{
> +   u64 fb_base = screen_info.lfb_base;
> +
> +   if (screen_info.capabilities & VIDEO_CAPABILITY_64BIT_BASE)
> +   fb_base |= (u64)(unsigned long)screen_info.ext_lfb_base << 32;
> +
> +   return fb_base >= range->cpu_addr &&
> +  fb_base < (range->cpu_addr + range->size);
> +}
> +
> +static struct device_node *find_pci_overlap_node(void)
> +{
> +   struct device_node *np;
> +
> +   for_each_node_by_type(np, "pci") {
> +   struct of_pci_range_parser parser;
> +   struct of_pci_range range;
> +   int err;
> +
> +   err = of_pci_range_parser_init(&parser, np);
> +   if (err) {
> +   pr_warn("of_pci_range_parser_init() failed: %d\n", 
> err);
> +   continue;
> +   }
> +
> +   for_each_of_pci_range(&parser, &range)
> +   if (efifb_overlaps_pci_range(&range))
> +   return np;
> +   }
> +   return NULL;
> +}
> +
> +/*
> + * If the efifb framebuffer is backed by a PCI graphics controller, we have
> + * to ensure that this relation is expressed using a device link when
> + * running in DT mode, or the probe order may be reversed, resulting in a
> + * resource reservation conflict on the memory window that the efifb
> + * framebuffer steals from the PCIe host bridge.
> + */
> +static int efifb_add_links(const struct fwnode_handle *fwnode,
> +  struct device *dev)
> +{
> +   struct device_node *sup_np;
> +   struct device *sup_dev;
> +
> +   sup_np = find_pci_overlap_node();
> +
> +   /*
> +* If there's no PCI graphics controller backing the efifb, we are
> +* done here.
> +*/
> +   if (!sup_np)
> +   return 0;
> +
> +   sup_dev = get_dev_from_fwnode(&sup_np->fwnode);
> +   of_node_put(sup_np);
> +
> +   /*
> +* Return -ENODEV if the PCI graphics controller device hasn't been
> +* registered yet.  This ensures that efifb isn't allowed to probe
> +* and this function is retried again when new devices are
> +* registered.
> +*/
> +   if (!sup_dev)
> +   return -ENODEV;
> +
> +   /*
> +* If this fails, retrying this function at a later point won't
> +* change anything. So, don't return an error after this.
> +*/
> +   if (!device_link_add(dev, sup_dev, 0))
> +   dev_warn(dev, "device_link_add() failed\n");
> +
> +   put_device(sup_dev);
> +
> +   return 0;
> +}
> +
> +static const struct fwnode_operations efifb_fwnode_ops = {
> +   .add_links = efifb_add_links,
> +};
> +
> +static struct fwnode_handle efifb_fwnode = {
> +   .ops = &efifb_fwnode_ops,
> +};
> +
>  static int __init register_gop_device(void)
>  {
> -   void *pd;
> +   struct platform_device *pd;
> +   int err;
>
> if (screen_info.orig_video_isVGA != VIDEO_TYPE_EFI)
> return 0;
>
> -   pd = pla

[rcu:dev.2020.09.16b] BUILD SUCCESS 7e3758bc1e241442177aee0d063bf2b9c92599b2

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git  
dev.2020.09.16b
branch HEAD: 7e3758bc1e241442177aee0d063bf2b9c92599b2  refscale: Prevent hangs 
for invalid arguments

elapsed time: 722m

configs tested: 90
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
s390   zfcpdump_defconfig
arm davinci_all_defconfig
s390defconfig
m68k allyesconfig
powerpc akebono_defconfig
arc nsimosci_hs_smp_defconfig
powerpc rainier_defconfig
mips   capcella_defconfig
powerpc kilauea_defconfig
powerpc  ppc6xx_defconfig
arc nps_defconfig
arm   h5000_defconfig
mipsbcm47xx_defconfig
armneponset_defconfig
mips  cavium_octeon_defconfig
x86_64   allyesconfig
nios2 10m50_defconfig
powerpcfsp2_defconfig
mips   lemote2f_defconfig
ia64 allmodconfig
ia64defconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
alphaallyesconfig
xtensa   allyesconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
nios2   defconfig
arc  allyesconfig
nds32 allnoconfig
c6x  allyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a004-20200917
i386 randconfig-a006-20200917
i386 randconfig-a003-20200917
i386 randconfig-a001-20200917
i386 randconfig-a002-20200917
i386 randconfig-a005-20200917
x86_64   randconfig-a014-20200917
x86_64   randconfig-a011-20200917
x86_64   randconfig-a016-20200917
x86_64   randconfig-a012-20200917
x86_64   randconfig-a015-20200917
x86_64   randconfig-a013-20200917
i386 randconfig-a015-20200917
i386 randconfig-a014-20200917
i386 randconfig-a011-20200917
i386 randconfig-a013-20200917
i386 randconfig-a016-20200917
i386 randconfig-a012-20200917
riscvnommu_k210_defconfig
riscvallyesconfig
riscvnommu_virt_defconfig
riscv allnoconfig
riscv   defconfig
riscv  rv32_defconfig
riscvallmodconfig
x86_64   rhel
x86_64rhel-7.6-kselftests
x86_64  defconfig
x86_64   rhel-8.3
x86_64  kexec

clang tested configs:
x86_64   randconfig-a006-20200917
x86_64   randconfig-a004-20200917
x86_64   randconfig-a003-20200917
x86_64   randconfig-a002-20200917
x86_64   randconfig-a001-20200917
x86_64   randconfig-a005-20200917

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

Re: [PATCH v2] software_node: Add support for fwnode_graph*() family of functions

[Sakari Ailus]

Hi Dan,

On Wed, Sep 16, 2020 at 02:22:10PM +0100, Dan Scally wrote:
> Hi Sakari - thanks for the comments
> 
> On 16/09/2020 10:17, Sakari Ailus wrote:
> > Moi Daniel and Heikki,
> >
> > On Wed, Sep 16, 2020 at 12:28:27AM +0100, Daniel Scally wrote:
> >> From: Heikki Krogerus 
> >>
> >> This implements the remaining .graph_* callbacks in the
> >> fwnode operations vector for the software nodes. That makes
> >> the fwnode_graph*() functions available in the drivers also
> >> when software nodes are used.
> >>
> >> The implementation tries to mimic the "OF graph" as much as
> >> possible, but there is no support for the "reg" device
> >> property. The ports will need to have the index in their
> >> name which starts with "port" (for example "port0", "port1",
> >> ...) and endpoints will use the index of the software node
> >> that is given to them during creation. The port nodes can
> >> also be grouped under a specially named "ports" subnode,
> >> just like in DT, if necessary.
> >>
> >> The remote-endpoints are reference properties under the
> >> endpoint nodes that are named "remote-endpoint". 
> >>
> >> Signed-off-by: Heikki Krogerus 
> >> Co-developed-by: Daniel Scally 
> >> Signed-off-by: Daniel Scally 
> >> ---
> >> changes in v2:
> >>- added software_node_device_is_available
> >>- altered software_node_get_next_child to get references
> >>- altered software_node_get_next_endpoint to release references
> >>to ports and avoid passing invalid combinations of swnodes to
> >>software_node_get_next_child
> >>- altered swnode_graph_find_next_port to release port rather than
> >>old
> >>
> >>  drivers/base/swnode.c | 129 +-
> >>  1 file changed, 127 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/base/swnode.c b/drivers/base/swnode.c
> >> index 010828fc785b..d69034b807e3 100644
> >> --- a/drivers/base/swnode.c
> >> +++ b/drivers/base/swnode.c
> >> @@ -363,6 +363,11 @@ static void software_node_put(struct fwnode_handle 
> >> *fwnode)
> >>kobject_put(&swnode->kobj);
> >>  }
> >>  
> >> +static bool software_node_device_is_available(const struct fwnode_handle 
> >> *fwnode)
> >> +{
> >> +  return is_software_node(fwnode);
> > This basically tells whether the device is there. Are there software node
> > based devices, i.e. do you need this?
> >
> > If you do really need this, then I guess this could just return true for
> > now as if you somehow get here, the node is a software node anyway.
> 
> I do think its better to include it; I'm targeting using this with
> ipu3-cio2; the cio2_parse_firmware() call there doesn't pass
> FWNODE_GRAPH_DEVICE_DISABLED to fwnode_graph_get_endpoint_by_id() so

I wonder if this has something to do with replacing the device's fwnode
in the cio2-bridge patch.

It's the device that needs to be enabled, and it's not a software node.

-- 
Regards,

Sakari Ailus

Re: [PATCH] MIPS: Loongson64: Add kexec/kdump support

[Jinyang He]

On 09/17/2020 10:21 PM, Jiaxun Yang wrote:



在 2020/9/17 20:41, Jinyang He 写道:

Hi, Huacai,


On 09/16/2020 01:39 PM, Huacai Chen wrote:

Hi, Jinyang,

On Tue, Sep 15, 2020 at 10:17 PM Jinyang He  
wrote:



On 09/16/2020 09:33 AM, Jiaxun Yang wrote:
于 2020年9月15日 GMT+08:00 下午9:07:43, Jinyang He 
 写到:

Add loongson_kexec_prepare(), loongson_kexec_shutdown() and
loongson_kexec_crashdown() for passing the parameters of kexec_args.

To start loongson64, CPU0 needs 3 parameters:
fw_arg0: the number of cmd.
fw_arg1: cmd structure which seems strange, the cmd array[index]'s
  value is cmd string's address, index >= 1.
fw_arg2: environment.

Secondary CPUs do not need parameter at once. They query their
mailbox to get PC, SP and GP in a loop before CPU0 brings them up
and passes these parameters via mailbox.

loongson_kexec_prepare(): Alloc new memory to save cmd for kexec.
Combine the kexec append option string as cmd structure, and the cmd
struct will be parsed in fw_init_cmdline() of 
arch/mips/fw/lib/cmdline.c.
image->control_code_page need pointing to a safe memory page. In 
order to

maintain compatibility for the old firmware the low 2MB is reserverd
and safe for Loongson. So let it points here.

loongson_kexec_shutdown(): Wake up all present CPUs and let them go
to reboot_code_buffer. Pass the kexec parameters to kexec_args.

loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.

The assembly part provide a way like BIOS doing to keep secondary
CPUs in a querying loop.

This patch referenced [1][2][3].

[1] arch/mips/cavium-octeon/setup.c
[2] https://patchwork.kernel.org/patch/10799217/
[3] 
https://gitee.com/loongsonlab/qemu/blob/master/hw/mips/loongson3a_rom.h 



Co-developed-by: Youling Tang 
Signed-off-by: Youling Tang 
Signed-off-by: Jinyang He 
---
arch/mips/kernel/relocate_kernel.S | 19 
arch/mips/loongson64/reset.c   | 88 
++

2 files changed, 107 insertions(+)

diff --git a/arch/mips/kernel/relocate_kernel.S 
b/arch/mips/kernel/relocate_kernel.S

index ac87089..061cbfb 100644
--- a/arch/mips/kernel/relocate_kernel.S
+++ b/arch/mips/kernel/relocate_kernel.S
@@ -133,6 +133,25 @@ LEAF(kexec_smp_wait)
#else
  sync
#endif
+
+#ifdef CONFIG_CPU_LOONGSON64
+#define MAILBOX_BASE 0x90003ff01000
Please avoid hardcoded SMP information. You're breaking Loongson 
3B support.



Ok, I see. Since my machine is Loongson 3A. I'll send v2
after I test it in 3B.

1, My original version can work on both Loongson-3A and Loongson-3B,
why you modify my patch and hadn't discuss with me?

2, With this single patch both kexec and kdump cannot work reliably,
because kexec need this patch:
https://patchwork.kernel.org/patch/11695929/

and kdump need my first patch in my original version:
https://patchwork.kernel.org/patch/10799215/

You may argue that you have tested. Yes, I believe that, I'm not
saying that you haven't test, and I'm not saying that your patch
cannot work, I'm just saying that your patch is not robust.

3, I'm the original author and paying attention to kexec/kdump
continuosly, I will send a new version once the above two patches be
accepted. But you re-send my patch without any communication with me,
why you so impatient?

Huacai



1, Your original version:
   https://patchwork.kernel.org/patch/10799217/

This patch can work on Loongson-3A, I tested it.

But it works wrong after the follow behaviors,
   kexec -l vmlinux --append=cmdline_kexec
   kexec -p vmlinux --append=cmdline_kdump
   kexec -e

It works but cmdline_kdump merged cmdline_kexec.

And this patch memcpy from fw_arg2 to kexec_envp and later memcpy from
kexec_envp to fw_arg2 when fw_arg2 was not changed, it's redundant.

However, I have not Loongson-3B now, and did not test it. For this 
patch,

does it work well on Loongson-3B3000/Loongson-3B4000?


Hi Jingyang,

Well for Loongson-3B I meant 3B1000/3B1500, which have different layout
of SMP registers. For 3B3000/3B4000 everyone know they're just different
branding to the same silicon.


OK, I see. Thank you.



3, I try to fix Loongson64 kexec function since I joined the community.
I fell sorry to not do enough research on Loongson64 kexec. My first 
patch:

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


I'm glad to see Loongson staff joining the community and enhance our 
code.
It is common practice to investigate historical changes before do 
something

to the upstream code :-)



It fixed problem about "Crash kernel" which can be traced back to 
linux-5.4.
At that time, I thought there is no developer work on Kexec. Thus, I 
did a
lot on Kexec. Are you really continuosly paying attention to 
kexec/kdump?
With the exploring and developing deep, I found your patch several 
days ago

after I did a draft patch witch referenced:
   arch/mips/cavium-octeon/setup.c
https://gitee.com/loongsonlab/qemu/blob/master/hw/mips/loongson3a_rom.h

There is no doubt that your patch gives me confidence and sugge

Re: [linux-next PATCH] rapidio: Fix error handling path

[Dan Carpenter]

On Fri, Sep 18, 2020 at 07:55:05AM +0530, Souptick Joarder wrote:
> Hi Dan,
> 
> On Thu, Sep 17, 2020 at 6:10 PM Dan Carpenter  
> wrote:
> >
> > On Wed, Sep 16, 2020 at 01:02:32PM +0300, Dan Carpenter wrote:
> > > On Wed, Sep 16, 2020 at 09:12:17AM +0530, Souptick Joarder wrote:
> > > > There is an error when pin_user_pages_fast() returns -ERRNO and
> > > > inside error handling path driver end up calling unpin_user_pages()
> > > > with -ERRNO which is not correct.
> > > >
> > > > This patch will fix the problem.
> > >
> > > There are a few ways we could prevent bug in the future.
> > >
> > > 1) This could have been caught with existing static analysis tools
> > >which warn about when a value is set but not used.
> > >
> > > 2) I've created a Smatch check which warngs about:
> > >
> > >   drivers/rapidio/devices/rio_mport_cdev.c:955 rio_dma_transfer() 
> > > warn: unpinning negative pages 'nr_pages'
> > >
> > >I'll test it out tonight and see how well it works.  I don't
> > >immediately see any other bugs allthough Smatch doesn't like the code
> > >in siw_umem_release().  It uses "min_t(int" which suggests that
> > >negative pages are okay.
> > >
> > >  int to_free = min_t(int, PAGES_PER_CHUNK, num_pages);
> > >
> >
> > I only found one bug but I'm going to add unpin_user_pages_dirty_lock()
> > to the mix a retest.  There were a few other false positives.  In
> > reviewing the code, I noticed that orangefs_bufmap_map() is also buggy.
> >
> > I sort of feel like returning partial successes is not working.  We
> > could easily make a wrapper which either pins everything or it returns
> > an error code.
> >
> > drivers/misc/mic/scif/scif_rma.c:1399 __scif_pin_pages() warn: unpinning 
> > negative pages 'pinned_pages->nr_pages'
> >
> > drivers/misc/mic/scif/scif_rma.c
> >   1355  vmalloc_addr = true;
> >   1356
> >   1357  for (i = 0; i < nr_pages; i++) {
> >   1358  if (vmalloc_addr)
> >   1359  pinned_pages->pages[i] =
> >   1360  vmalloc_to_page(addr + (i * 
> > PAGE_SIZE));
> >   1361  else
> >   1362  pinned_pages->pages[i] =
> >   1363  virt_to_page(addr + (i * 
> > PAGE_SIZE));
> >   1364  }
> >   1365  pinned_pages->nr_pages = nr_pages;
> >   1366  pinned_pages->map_flags = SCIF_MAP_KERNEL;
> >   1367  } else {
> >   1368  /*
> >   1369   * SCIF supports registration caching. If a 
> > registration has
> >   1370   * been requested with read only permissions, then 
> > we try
> >   1371   * to pin the pages with RW permissions so that a 
> > subsequent
> >   1372   * transfer with RW permission can hit the cache 
> > instead of
> >   1373   * invalidating it. If the upgrade fails with RW 
> > then we
> >   1374   * revert back to R permission and retry
> >   1375   */
> >   1376  if (prot == SCIF_PROT_READ)
> >   1377  try_upgrade = true;
> >   1378  prot |= SCIF_PROT_WRITE;
> >   1379  retry:
> >   1380  mm = current->mm;
> >   1381  if (ulimit) {
> >   1382  err = __scif_check_inc_pinned_vm(mm, 
> > nr_pages);
> >   1383  if (err) {
> >   1384  pinned_pages->nr_pages = 0;
> >   1385  goto error_unmap;
> >   1386  }
> >   1387  }
> >   1388
> >   1389  pinned_pages->nr_pages = pin_user_pages_fast(
> >   1390  (u64)addr,
> >   1391  nr_pages,
> >   1392  (prot & SCIF_PROT_WRITE) ? 
> > FOLL_WRITE : 0,
> >   1393  pinned_pages->pages);
> >   1394  if (nr_pages != pinned_pages->nr_pages) {
> >   1395  if (try_upgrade) {
> >   1396  if (ulimit)
> >   1397  
> > __scif_dec_pinned_vm_lock(mm, nr_pages);
> >   1398  /* Roll back any pinned pages */
> >   1399  
> > unpin_user_pages(pinned_pages->pages,
> >   1400   
> > pinned_pages->nr_pages);
> >  
> > ^^
> > Negative.
> >
> >   1401  prot &= ~SCIF_PROT_WRITE;
> >   1402  try_upgrade = false;
> >   1403  goto retry;
> >   1404 

Re: [PATCH] MIPS: Loongson64: Add kexec/kdump support

[Jinyang He]

On 09/17/2020 09:52 PM, Zhou Yanjie wrote:

Hello,

在 2020/9/17 下午8:41, Jinyang He 写道:

Hi, Huacai,


On 09/16/2020 01:39 PM, Huacai Chen wrote:

Hi, Jinyang,

On Tue, Sep 15, 2020 at 10:17 PM Jinyang He  
wrote:



On 09/16/2020 09:33 AM, Jiaxun Yang wrote:
于 2020年9月15日 GMT+08:00 下午9:07:43, Jinyang He 
 写到:

Add loongson_kexec_prepare(), loongson_kexec_shutdown() and
loongson_kexec_crashdown() for passing the parameters of kexec_args.

To start loongson64, CPU0 needs 3 parameters:
fw_arg0: the number of cmd.
fw_arg1: cmd structure which seems strange, the cmd array[index]'s
  value is cmd string's address, index >= 1.
fw_arg2: environment.

Secondary CPUs do not need parameter at once. They query their
mailbox to get PC, SP and GP in a loop before CPU0 brings them up
and passes these parameters via mailbox.

loongson_kexec_prepare(): Alloc new memory to save cmd for kexec.
Combine the kexec append option string as cmd structure, and the cmd
struct will be parsed in fw_init_cmdline() of 
arch/mips/fw/lib/cmdline.c.
image->control_code_page need pointing to a safe memory page. In 
order to

maintain compatibility for the old firmware the low 2MB is reserverd
and safe for Loongson. So let it points here.

loongson_kexec_shutdown(): Wake up all present CPUs and let them go
to reboot_code_buffer. Pass the kexec parameters to kexec_args.

loongson_crash_shutdown(): Pass the kdump parameters to kexec_args.

The assembly part provide a way like BIOS doing to keep secondary
CPUs in a querying loop.

This patch referenced [1][2][3].

[1] arch/mips/cavium-octeon/setup.c
[2] https://patchwork.kernel.org/patch/10799217/
[3] 
https://gitee.com/loongsonlab/qemu/blob/master/hw/mips/loongson3a_rom.h 



Co-developed-by: Youling Tang 
Signed-off-by: Youling Tang 
Signed-off-by: Jinyang He 
---
arch/mips/kernel/relocate_kernel.S | 19 
arch/mips/loongson64/reset.c   | 88 
++

2 files changed, 107 insertions(+)

diff --git a/arch/mips/kernel/relocate_kernel.S 
b/arch/mips/kernel/relocate_kernel.S

index ac87089..061cbfb 100644
--- a/arch/mips/kernel/relocate_kernel.S
+++ b/arch/mips/kernel/relocate_kernel.S
@@ -133,6 +133,25 @@ LEAF(kexec_smp_wait)
#else
  sync
#endif
+
+#ifdef CONFIG_CPU_LOONGSON64
+#define MAILBOX_BASE 0x90003ff01000
Please avoid hardcoded SMP information. You're breaking Loongson 
3B support.



Ok, I see. Since my machine is Loongson 3A. I'll send v2
after I test it in 3B.

1, My original version can work on both Loongson-3A and Loongson-3B,
why you modify my patch and hadn't discuss with me?

2, With this single patch both kexec and kdump cannot work reliably,
because kexec need this patch:
https://patchwork.kernel.org/patch/11695929/

and kdump need my first patch in my original version:
https://patchwork.kernel.org/patch/10799215/

You may argue that you have tested. Yes, I believe that, I'm not
saying that you haven't test, and I'm not saying that your patch
cannot work, I'm just saying that your patch is not robust.

3, I'm the original author and paying attention to kexec/kdump
continuosly, I will send a new version once the above two patches be
accepted. But you re-send my patch without any communication with me,
why you so impatient?

Huacai



1, Your original version:
   https://patchwork.kernel.org/patch/10799217/

This patch can work on Loongson-3A, I tested it.

But it works wrong after the follow behaviors,
   kexec -l vmlinux --append=cmdline_kexec
   kexec -p vmlinux --append=cmdline_kdump
   kexec -e



What 's wrong with you Loongson guys? Why do you always send patches 
with the same functions as the original author withou any 
communication with the original author? Especially the original author 
of the patch is the maintainer of Loongson64 architecture.


Hi,

Just take it easy, try to keep calm and do not panic.

You do not understand the story, the background, what happened before,
and what happens next, so please let me express my opinion.

When I use the mainline kernel on the Loongson platform, I find kexec
can not work well and I feel depressed, so I analyse and debug the
related code, the initial aim of all my effort is to make it work well.

In order to create the positive environment of community participation,
I have two questions to discuss:
(1) If there exists a similar patch which is submitted more than one
year ago but has not been merged into the mainline tree, could the
newcomers do the similar work to support the same feature? I think the
answer is yes, right?
(2) When the newcomers submit the new patch to community, what should
be done to avoid an unhappy time? I think this is the nature of the
problem, add "Originally-by:" tag? What do you think of it?

I think we should consider what is the proper attitude to welcome and
encourage newcomers, however terrible or wrong things they did,
everyone needs to have a process of growth, right?

Positive and well-meant suggestions would be much 

Re: [PATCH printk 2/3] printk: move dictionary keys to dev_printk_info

[Rasmus Villemoes]

On 17/09/2020 15.16, John Ogness wrote:

>   if (dev->class)
>   subsys = dev->class->name;
>   else if (dev->bus)
>   subsys = dev->bus->name;
>   else
> - return 0;
> + return;
>  
> - pos += snprintf(hdr + pos, hdrlen - pos, "SUBSYSTEM=%s", subsys);
> - if (pos >= hdrlen)
> - goto overflow;
> + snprintf(dev_info->subsystem, sizeof(dev_info->subsystem), subsys);

It's unlikely that subsys would contain a %, but this will be yet
another place to spend brain cycles ignoring if doing static analysis.
So can we not do this. Either of strXcpy() for X=s,l will do the same
thing, and likely faster.

Rasmus

Re: [PATCH leds v2 05/50] leds: various: guard of_match_table member value with of_match_ptr

[Sakari Ailus]

Hi Marek,

On Fri, Sep 18, 2020 at 12:32:53AM +0200, Marek Behún wrote:
> Change
>   .of_match_table = xxx,
> to
>   .of_match_table = of_match_ptr(xxx),
> in various drivers.
> 
> This should be standard even for drivers that depend on OF.

After this patch, none of these drivers will work on ACPI systems anymore.

How many of them really depend on OF?

-- 
Regards,

Sakari Ailus

[PATCH v2] ptp: mark symbols static where possible

[Herrington]

We get 1 warning when building kernel with W=1:
drivers/ptp/ptp_pch.c:182:5: warning: no previous prototype for 
‘pch_ch_control_read’ [-Wmissing-prototypes]
 u32 pch_ch_control_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:193:6: warning: no previous prototype for 
‘pch_ch_control_write’ [-Wmissing-prototypes]
 void pch_ch_control_write(struct pci_dev *pdev, u32 val)
drivers/ptp/ptp_pch.c:201:5: warning: no previous prototype for 
‘pch_ch_event_read’ [-Wmissing-prototypes]
 u32 pch_ch_event_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:212:6: warning: no previous prototype for 
‘pch_ch_event_write’ [-Wmissing-prototypes]
 void pch_ch_event_write(struct pci_dev *pdev, u32 val)
drivers/ptp/ptp_pch.c:220:5: warning: no previous prototype for 
‘pch_src_uuid_lo_read’ [-Wmissing-prototypes]
 u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:231:5: warning: no previous prototype for 
‘pch_src_uuid_hi_read’ [-Wmissing-prototypes]
 u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:242:5: warning: no previous prototype for 
‘pch_rx_snap_read’ [-Wmissing-prototypes]
 u64 pch_rx_snap_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:259:5: warning: no previous prototype for 
‘pch_tx_snap_read’ [-Wmissing-prototypes]
 u64 pch_tx_snap_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:300:5: warning: no previous prototype for 
‘pch_set_station_address’ [-Wmissing-prototypes]
 int pch_set_station_address(u8 *addr, struct pci_dev *pdev)

Signed-off-by: Herrington 
---
 drivers/ptp/ptp_pch.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index ce10ecd41ba0..70eee68e8dfc 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -179,7 +179,7 @@ static inline void pch_block_reset(struct pch_dev *chip)
iowrite32(val, (&chip->regs->control));
 }
 
-u32 pch_ch_control_read(struct pci_dev *pdev)
+static u32 pch_ch_control_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
u32 val;
@@ -190,6 +190,7 @@ u32 pch_ch_control_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_ch_control_read);
 
+void pch_ch_control_write(struct pci_dev *pdev, u32 val);
 void pch_ch_control_write(struct pci_dev *pdev, u32 val)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -198,6 +199,7 @@ void pch_ch_control_write(struct pci_dev *pdev, u32 val)
 }
 EXPORT_SYMBOL(pch_ch_control_write);
 
+u32 pch_ch_event_read(struct pci_dev *pdev);
 u32 pch_ch_event_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -209,6 +211,7 @@ u32 pch_ch_event_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_ch_event_read);
 
+void pch_ch_event_write(struct pci_dev *pdev, u32 val);
 void pch_ch_event_write(struct pci_dev *pdev, u32 val)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -217,6 +220,7 @@ void pch_ch_event_write(struct pci_dev *pdev, u32 val)
 }
 EXPORT_SYMBOL(pch_ch_event_write);
 
+u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
 u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -228,6 +232,7 @@ u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_src_uuid_lo_read);
 
+u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
 u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -239,6 +244,7 @@ u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_src_uuid_hi_read);
 
+u64 pch_rx_snap_read(struct pci_dev *pdev);
 u64 pch_rx_snap_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -256,6 +262,7 @@ u64 pch_rx_snap_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_rx_snap_read);
 
+u64 pch_tx_snap_read(struct pci_dev *pdev);
 u64 pch_tx_snap_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -297,6 +304,7 @@ static void pch_reset(struct pch_dev *chip)
  * traffic on the  ethernet interface
  * @addr:  dress which contain the column separated address to be used.
  */
+int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
 int pch_set_station_address(u8 *addr, struct pci_dev *pdev)
 {
s32 i;
-- 
2.18.1

[PATCH v6 5/5] ASoC: qcom: sc7180: Add support for audio over DP

[Srinivasa Rao Mandadapu]

From: V Sujith Kumar Reddy 

Add support for audio playback over DP in lpass sc7180 platform driver.
Update lpass_variant structure for hdmi data configuaration.

Signed-off-by: Srinivasa Rao 
Signed-off-by: V Sujith Kumar Reddy 
---
 sound/soc/qcom/lpass-sc7180.c | 116 +-
 1 file changed, 102 insertions(+), 14 deletions(-)

diff --git a/sound/soc/qcom/lpass-sc7180.c b/sound/soc/qcom/lpass-sc7180.c
index 167bf2c..59f115e 100644
--- a/sound/soc/qcom/lpass-sc7180.c
+++ b/sound/soc/qcom/lpass-sc7180.c
@@ -60,38 +60,65 @@ static struct snd_soc_dai_driver 
sc7180_lpass_cpu_dai_driver[] = {
.probe  = &asoc_qcom_lpass_cpu_dai_probe,
.ops= &asoc_qcom_lpass_cpu_dai_ops,
},
+   [LPASS_DP_RX] = {
+   .id = LPASS_DP_RX,
+   .name = "Hdmi",
+   .playback = {
+   .stream_name = "Hdmi Playback",
+   .formats= SNDRV_PCM_FMTBIT_S24,
+   .rates = SNDRV_PCM_RATE_48000,
+   .rate_min   = 48000,
+   .rate_max   = 48000,
+   .channels_min   = 2,
+   .channels_max   = 2,
+   },
+   .ops= &asoc_qcom_lpass_hdmi_dai_ops,
+   },
 };
 
 static int sc7180_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
 
-   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
-   chan = find_first_zero_bit(&drvdata->dma_ch_bit_map,
-   v->rdma_channels);
+   if (dai_id == LPASS_DP_RX) {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = 
find_first_zero_bit(&drvdata->hdmi_dma_ch_bit_map,
+   v->hdmi_rdma_channels);
+
+   if (chan >= v->hdmi_rdma_channels)
+   return -EBUSY;
+   }
+   set_bit(chan, &drvdata->hdmi_dma_ch_bit_map);
+   } else {
+   if (direction == SNDRV_PCM_STREAM_PLAYBACK) {
+   chan = find_first_zero_bit(&drvdata->dma_ch_bit_map,
+   v->rdma_channels);
 
if (chan >= v->rdma_channels)
return -EBUSY;
-   } else {
-   chan = find_next_zero_bit(&drvdata->dma_ch_bit_map,
+   } else {
+   chan = find_next_zero_bit(&drvdata->dma_ch_bit_map,
v->wrdma_channel_start +
v->wrdma_channels,
v->wrdma_channel_start);
 
-   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
-   return -EBUSY;
-   }
-
-   set_bit(chan, &drvdata->dma_ch_bit_map);
+   if (chan >=  v->wrdma_channel_start + v->wrdma_channels)
+   return -EBUSY;
+   }
 
+   set_bit(chan, &drvdata->dma_ch_bit_map);
+   }
return chan;
 }
 
-static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int sc7180_lpass_free_dma_channel(struct lpass_data *drvdata, int chan, 
unsigned int dai_id)
 {
-   clear_bit(chan, &drvdata->dma_ch_bit_map);
+   if (dai_id == LPASS_DP_RX)
+   clear_bit(chan, &drvdata->hdmi_dma_ch_bit_map);
+   else
+   clear_bit(chan, &drvdata->dma_ch_bit_map);
 
return 0;
 }
@@ -144,6 +171,9 @@ static struct lpass_variant sc7180_data = {
.rdma_reg_base  = 0xC000,
.rdma_reg_stride= 0x1000,
.rdma_channels  = 5,
+   .hdmi_rdma_reg_base = 0x64000,
+   .hdmi_rdma_reg_stride   = 0x1000,
+   .hdmi_rdma_channels = 4,
.dmactl_audif_start = 1,
.wrdma_reg_base = 0x18000,
.wrdma_reg_stride   = 0x1000,
@@ -163,7 +193,7 @@ static struct lpass_variant sc7180_data = {
.rdma_dyncclk   = REG_FIELD_ID(0xC000, 21, 21, 5, 0x1000),
.rdma_bursten   = REG_FIELD_ID(0xC000, 20, 20, 5, 0x1000),
.rdma_wpscnt= REG_FIELD_ID(0xC000, 16, 19, 5, 0x1000),
-   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 0x1000),
+   .rdma_intf  = REG_FIELD_ID(0xC000, 12, 15, 5, 
0x1000),
.rdma_fifowm= REG_FIELD_ID(0xC000, 1, 5, 5, 0x1000),
.rdma_enable= REG_FIELD_ID(0xC000, 0, 0, 5, 0x1000),
 
@@ -174,6 +204,64 @@ static struct lpass_variant sc7180_data = {
.wrdma_fifowm   = REG_FIELD_ID(0x18000, 1, 5, 4, 0x1000),
.wrdma_enable   = REG_FIE

[PATCH] [PATCH v2]ptp: mark symbols static where possible

[Herrington]

We get 1 warning when building kernel with W=1:
drivers/ptp/ptp_pch.c:182:5: warning: no previous prototype for 
‘pch_ch_control_read’ [-Wmissing-prototypes]
 u32 pch_ch_control_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:193:6: warning: no previous prototype for 
‘pch_ch_control_write’ [-Wmissing-prototypes]
 void pch_ch_control_write(struct pci_dev *pdev, u32 val)
drivers/ptp/ptp_pch.c:201:5: warning: no previous prototype for 
‘pch_ch_event_read’ [-Wmissing-prototypes]
 u32 pch_ch_event_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:212:6: warning: no previous prototype for 
‘pch_ch_event_write’ [-Wmissing-prototypes]
 void pch_ch_event_write(struct pci_dev *pdev, u32 val)
drivers/ptp/ptp_pch.c:220:5: warning: no previous prototype for 
‘pch_src_uuid_lo_read’ [-Wmissing-prototypes]
 u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:231:5: warning: no previous prototype for 
‘pch_src_uuid_hi_read’ [-Wmissing-prototypes]
 u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:242:5: warning: no previous prototype for 
‘pch_rx_snap_read’ [-Wmissing-prototypes]
 u64 pch_rx_snap_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:259:5: warning: no previous prototype for 
‘pch_tx_snap_read’ [-Wmissing-prototypes]
 u64 pch_tx_snap_read(struct pci_dev *pdev)
drivers/ptp/ptp_pch.c:300:5: warning: no previous prototype for 
‘pch_set_station_address’ [-Wmissing-prototypes]
 int pch_set_station_address(u8 *addr, struct pci_dev *pdev)

Signed-off-by: Herrington 
---
 drivers/ptp/ptp_pch.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/ptp/ptp_pch.c b/drivers/ptp/ptp_pch.c
index ce10ecd41ba0..70eee68e8dfc 100644
--- a/drivers/ptp/ptp_pch.c
+++ b/drivers/ptp/ptp_pch.c
@@ -179,7 +179,7 @@ static inline void pch_block_reset(struct pch_dev *chip)
iowrite32(val, (&chip->regs->control));
 }
 
-u32 pch_ch_control_read(struct pci_dev *pdev)
+static u32 pch_ch_control_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
u32 val;
@@ -190,6 +190,7 @@ u32 pch_ch_control_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_ch_control_read);
 
+void pch_ch_control_write(struct pci_dev *pdev, u32 val);
 void pch_ch_control_write(struct pci_dev *pdev, u32 val)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -198,6 +199,7 @@ void pch_ch_control_write(struct pci_dev *pdev, u32 val)
 }
 EXPORT_SYMBOL(pch_ch_control_write);
 
+u32 pch_ch_event_read(struct pci_dev *pdev);
 u32 pch_ch_event_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -209,6 +211,7 @@ u32 pch_ch_event_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_ch_event_read);
 
+void pch_ch_event_write(struct pci_dev *pdev, u32 val);
 void pch_ch_event_write(struct pci_dev *pdev, u32 val)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -217,6 +220,7 @@ void pch_ch_event_write(struct pci_dev *pdev, u32 val)
 }
 EXPORT_SYMBOL(pch_ch_event_write);
 
+u32 pch_src_uuid_lo_read(struct pci_dev *pdev);
 u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -228,6 +232,7 @@ u32 pch_src_uuid_lo_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_src_uuid_lo_read);
 
+u32 pch_src_uuid_hi_read(struct pci_dev *pdev);
 u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -239,6 +244,7 @@ u32 pch_src_uuid_hi_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_src_uuid_hi_read);
 
+u64 pch_rx_snap_read(struct pci_dev *pdev);
 u64 pch_rx_snap_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -256,6 +262,7 @@ u64 pch_rx_snap_read(struct pci_dev *pdev)
 }
 EXPORT_SYMBOL(pch_rx_snap_read);
 
+u64 pch_tx_snap_read(struct pci_dev *pdev);
 u64 pch_tx_snap_read(struct pci_dev *pdev)
 {
struct pch_dev *chip = pci_get_drvdata(pdev);
@@ -297,6 +304,7 @@ static void pch_reset(struct pch_dev *chip)
  * traffic on the  ethernet interface
  * @addr:  dress which contain the column separated address to be used.
  */
+int pch_set_station_address(u8 *addr, struct pci_dev *pdev);
 int pch_set_station_address(u8 *addr, struct pci_dev *pdev)
 {
s32 i;
-- 
2.18.1

[PATCH v6 0/5] Qualcomm's lpass-hdmi ASoC driver to support audio over dp port

[Srinivasa Rao Mandadapu]

These patches are to support audio over DP port on Qualcomm's SC7180 LPASS Asoc.
It includes machine driver, cpu driver, platform driver updates for HDMI path 
support, 
device tree documention, lpass variant structure optimization and configuration 
changes.
These patches depends on the DP patch series 
https://patchwork.kernel.org/project/dri-devel/list/?series=332029

changes since V5:
-- Removed unused struct regmap *map in 
lpass_platform_alloc_hdmidmactl_fields.
-- DMA alloc and free API signature change in lpass-apq8016.c, 
lpass-ipq806x.c 
-- Keeping API "irqreturn_t lpass_platform_hdmiif_irq" under ifdef macro
Changes Since v4:
-- Updated with single compatible node for both I2S and HDMI.
Changes Since v3:
-- Removed id in lpass variant structure and used snd_soc_dai_driver id.
Changes Since v2:
-- Audio buffer size(i.e. LPASS_PLATFORM_BUFFER_SIZE) in 
lpass-platform.c increased.
Changes Since v1:
-- Commit messages are updated
-- Addressed Rob Herring review comments

V Sujith Kumar Reddy (5):
  ASoC: Add sc7180-lpass binding header hdmi define
  ASoC: dt-bindings: Add dt binding for lpass hdmi
  Asoc:qcom:lpass-cpu:Update dts property read API
  ASoC: qcom: Add support for lpass hdmi driver
  ASoC: qcom: sc7180: Add support for audio over DP

 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  |  74 ++-
 include/dt-bindings/sound/sc7180-lpass.h   |   1 +
 sound/soc/qcom/Kconfig |   5 +
 sound/soc/qcom/Makefile|   2 +
 sound/soc/qcom/lpass-apq8016.c |   4 +-
 sound/soc/qcom/lpass-cpu.c |  39 +-
 sound/soc/qcom/lpass-hdmi.c| 596 +
 sound/soc/qcom/lpass-hdmi.h| 129 +
 sound/soc/qcom/lpass-ipq806x.c |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h   |  52 +-
 sound/soc/qcom/lpass-platform.c| 468 
 sound/soc/qcom/lpass-sc7180.c  | 116 +++-
 sound/soc/qcom/lpass.h | 119 +++-
 13 files changed, 1451 insertions(+), 158 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH v1 4/6] wdt: Support wdt on ROHM BD9576MUF and BD9573MUF

[Vaittinen, Matti]

Thanks (again) for review Guenter!

On Thu, 2020-09-17 at 22:45 -0700, Guenter Roeck wrote:
> On 9/17/20 1:03 AM, Matti Vaittinen wrote:
> > Add Watchdog support for ROHM BD9576MUF and BD9573MUF PMICs which
> > are
> > mainly used to power the R-Car series processors. The watchdog is
> > pinged using a GPIO and enabled using another GPIO. Additionally
> > watchdog time-out can be configured to HW prior starting the
> > watchdog.
> > Watchdog timeout can be configured to detect only delayed ping or
> > in
> > a window mode where also too fast pings are detected.
> > 
> > Signed-off-by: Matti Vaittinen 
> > ---
> >  drivers/watchdog/Kconfig  |  13 ++
> >  drivers/watchdog/Makefile |   1 +
> >  drivers/watchdog/bd9576_wdt.c | 295
> > ++
> >  3 files changed, 309 insertions(+)
> >  create mode 100644 drivers/watchdog/bd9576_wdt.c

> 
> > +
> > +   ret = of_property_read_u32(np,
> > +  "hw_margin_ms", &hw_margin);
> 
> Line splits are arbitrary. Why is this "hw_margin_ms" and not
> "rohm,hw_margin_ms" ?

"hw_margin_ms" is an existing binding for specifying the maximum TMO in
HW (if I understood it correctly). (It is used at least by the generig
GPIO watchdog) I thought it's better to not invent a new vendor
specific binding when we have a generic one.

https://elixir.bootlin.com/linux/v5.9-rc2/source/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt

> 
> > +   if (ret) {
> > +   if (ret != -EINVAL)
> > +   return ret;
> > +
> > +   hw_margin = BD957X_WDT_DEFAULT_MARGIN;
> > +   }
> > +
> > +   ret = of_property_read_u32(np, "rohm,hw-margin-min-ms",
> > &hw_margin_min);
> > +   if (ret == -EINVAL)
> > +   hw_margin_min = 0;
> > +   else if (ret)
> > +   return ret;
> 
> Please use a single mechanism to handle -EINVAL after
> of_property_read_u32().

Sorry Guenter - I am probably a bit slow today but I am unsure if I
understand the suggestion. Do you mean something like:

hw_margin_min = 0;

ret = of_property_read_u32(np, "rohm,hw-margin-min-ms",
&hw_margin_min);
if (ret && ret != -EINVAL)
return ret;

Other than that - all findings are clear to me. I'll craft a new
version but I'll wait for a while to see if Lee has time to send some
feedback on MFD so I could get both WDG and MFD fixes to same version
:)

Best Regards
--Matti


--
Matti Vaittinen, Linux device drivers
ROHM Semiconductors, Finland
SWDC
Kiviharjunlenkki 1E
90220 OULU
FINLAND

~~~ "I don't think so," said Rene Descartes. Just then he vanished ~~~

Simon says - in Latin please.
"non cogito me" dixit Rene Descarte, deinde evanescavit

(Thanks for the translation Simon)

[PATCH v6 4/5] ASoC: qcom: Add support for lpass hdmi driver

[Srinivasa Rao Mandadapu]

From: V Sujith Kumar Reddy 

Upadate lpass cpu and platform driver to support audio over dp.
Also add lpass-hdmi.c and lpass-hdmi.h.

Signed-off-by: Srinivasa Rao 
Signed-off-by: V Sujith Kumar Reddy 
---
 sound/soc/qcom/Kconfig   |   5 +
 sound/soc/qcom/Makefile  |   2 +
 sound/soc/qcom/lpass-apq8016.c   |   4 +-
 sound/soc/qcom/lpass-cpu.c   |  37 ++-
 sound/soc/qcom/lpass-hdmi.c  | 596 +++
 sound/soc/qcom/lpass-hdmi.h  | 129 +
 sound/soc/qcom/lpass-ipq806x.c   |   4 +-
 sound/soc/qcom/lpass-lpaif-reg.h |  52 +++-
 sound/soc/qcom/lpass-platform.c  | 466 --
 sound/soc/qcom/lpass.h   | 119 +++-
 10 files changed, 1294 insertions(+), 120 deletions(-)
 create mode 100644 sound/soc/qcom/lpass-hdmi.c
 create mode 100644 sound/soc/qcom/lpass-hdmi.h

diff --git a/sound/soc/qcom/Kconfig b/sound/soc/qcom/Kconfig
index a607ace..509584c 100644
--- a/sound/soc/qcom/Kconfig
+++ b/sound/soc/qcom/Kconfig
@@ -12,6 +12,10 @@ config SND_SOC_LPASS_CPU
tristate
select REGMAP_MMIO
 
+config SND_SOC_LPASS_HDMI
+   tristate
+   select REGMAP_MMIO
+
 config SND_SOC_LPASS_PLATFORM
tristate
select REGMAP_MMIO
@@ -30,6 +34,7 @@ config SND_SOC_LPASS_SC7180
tristate
select SND_SOC_LPASS_CPU
select SND_SOC_LPASS_PLATFORM
+   select SND_SOC_LPASS_HDMI
 
 config SND_SOC_STORM
tristate "ASoC I2S support for Storm boards"
diff --git a/sound/soc/qcom/Makefile b/sound/soc/qcom/Makefile
index 7972c94..0bd90d7 100644
--- a/sound/soc/qcom/Makefile
+++ b/sound/soc/qcom/Makefile
@@ -1,12 +1,14 @@
 # SPDX-License-Identifier: GPL-2.0
 # Platform
 snd-soc-lpass-cpu-objs := lpass-cpu.o
+snd-soc-lpass-hdmi-objs := lpass-hdmi.o
 snd-soc-lpass-platform-objs := lpass-platform.o
 snd-soc-lpass-ipq806x-objs := lpass-ipq806x.o
 snd-soc-lpass-apq8016-objs := lpass-apq8016.o
 snd-soc-lpass-sc7180-objs := lpass-sc7180.o
 
 obj-$(CONFIG_SND_SOC_LPASS_CPU) += snd-soc-lpass-cpu.o
+obj-$(CONFIG_SND_SOC_LPASS_HDMI) += snd-soc-lpass-hdmi.o
 obj-$(CONFIG_SND_SOC_LPASS_PLATFORM) += snd-soc-lpass-platform.o
 obj-$(CONFIG_SND_SOC_LPASS_IPQ806X) += snd-soc-lpass-ipq806x.o
 obj-$(CONFIG_SND_SOC_LPASS_APQ8016) += snd-soc-lpass-apq8016.o
diff --git a/sound/soc/qcom/lpass-apq8016.c b/sound/soc/qcom/lpass-apq8016.c
index 5c8ae22..0aedb3a 100644
--- a/sound/soc/qcom/lpass-apq8016.c
+++ b/sound/soc/qcom/lpass-apq8016.c
@@ -125,7 +125,7 @@ static struct snd_soc_dai_driver 
apq8016_lpass_cpu_dai_driver[] = {
 };
 
 static int apq8016_lpass_alloc_dma_channel(struct lpass_data *drvdata,
-  int direction)
+  int direction, unsigned int dai_id)
 {
struct lpass_variant *v = drvdata->variant;
int chan = 0;
@@ -151,7 +151,7 @@ static int apq8016_lpass_alloc_dma_channel(struct 
lpass_data *drvdata,
return chan;
 }
 
-static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int chan)
+static int apq8016_lpass_free_dma_channel(struct lpass_data *drvdata, int 
chan, unsigned int dai_id)
 {
clear_bit(chan, &drvdata->dma_ch_bit_map);
 
diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 5d84f63..41a2470 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -589,13 +589,33 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
variant->wrdma_channel_start);
 
drvdata->lpaif_map = devm_regmap_init_mmio(dev, drvdata->lpaif,
-   &lpass_cpu_regmap_config);
+   
&lpass_cpu_regmap_config);
if (IS_ERR(drvdata->lpaif_map)) {
dev_err(dev, "error initializing regmap: %ld\n",
PTR_ERR(drvdata->lpaif_map));
return PTR_ERR(drvdata->lpaif_map);
}
+#ifdef CONFIG_SND_SOC_LPASS_SC7180
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, 
"lpass-hdmiif");
 
+   drvdata->hdmiif = devm_ioremap_resource(dev, res);
+   if (IS_ERR((void const __force *)drvdata->hdmiif)) {
+   dev_err(dev, "error mapping reg resource: %ld\n",
+   PTR_ERR((void const __force *)drvdata->hdmiif));
+   return PTR_ERR((void const __force *)drvdata->hdmiif);
+   }
+
+   lpass_hdmi_regmap_config.max_register = LPAIF_HDMI_RDMAPER_REG(variant,
+   variant->hdmi_rdma_channels);
+   drvdata->hdmiif_map = devm_regmap_init_mmio(dev, drvdata->hdmiif,
+   &lpass_hdmi_regmap_config);
+   if (IS_ERR(drvdata->hdmiif_map)) {
+   dev_err(dev, "error initializing regmap: %ld\n",
+   PTR_ERR(drvdata->hdmiif_map));
+   return PTR_ERR(drvdata->hdmiif_map);
+   }
+
+#endif
if (variant->init) {
   

[PATCH v6 1/5] ASoC: Add sc7180-lpass binding header hdmi define

[Srinivasa Rao Mandadapu]

From: V Sujith Kumar Reddy 

Add header defining hdmi dai-id for SC7180 lpass soc
in dt bindings.

Signed-off-by: Srinivasa Rao 
Signed-off-by: V Sujith Kumar Reddy 
Acked-by: Rob Herring 
---
 include/dt-bindings/sound/sc7180-lpass.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/dt-bindings/sound/sc7180-lpass.h 
b/include/dt-bindings/sound/sc7180-lpass.h
index 7d988f6..56ecaaf 100644
--- a/include/dt-bindings/sound/sc7180-lpass.h
+++ b/include/dt-bindings/sound/sc7180-lpass.h
@@ -4,6 +4,7 @@
 
 #define MI2S_PRIMARY   0
 #define MI2S_SECONDARY 1
+#define LPASS_DP_RX2
 
 #define LPASS_MCLK00
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v6 2/5] ASoC: dt-bindings: Add dt binding for lpass hdmi

[Srinivasa Rao Mandadapu]

From: V Sujith Kumar Reddy 

Adds bindings for lpass hdmi interface
which can support audio path over dp.

Signed-off-by: Srinivasa Rao 
Signed-off-by: V Sujith Kumar Reddy 
---
 .../devicetree/bindings/sound/qcom,lpass-cpu.yaml  | 74 +++---
 1 file changed, 52 insertions(+), 22 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml 
b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
index 09c9bd2..f95ef70 100644
--- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
+++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml
@@ -24,9 +24,10 @@ properties:
   - qcom,sc7180-lpass-cpu
 
   reg:
-maxItems: 1
+maxItems: 2
 description: LPAIF core registers
-
+  reg-names:
+ maxItems: 2
   clocks:
 minItems: 3
 maxItems: 6
@@ -36,15 +37,16 @@ properties:
 maxItems: 6
 
   interrupts:
-maxItems: 1
+maxItems: 2
 description: LPAIF DMA buffer interrupt
-
+  interrupt-names:
+maxItems: 2
   qcom,adsp:
 $ref: /schemas/types.yaml#/definitions/phandle
 description: Phandle for the audio DSP node
 
   iommus:
-maxItems: 1
+maxItems: 2
 description: Phandle to apps_smmu node with sid mask
 
   power-domains:
@@ -60,10 +62,12 @@ properties:
 const: 0
 
 patternProperties:
-  "(^mi2s-[0-9a-f]$|mi2s)":
+  "^dai-link@[0-9a-f]$":
 type: object
-description: Required properties for each DAI
-
+description: |
+  LPASS CPU dai node for each I2S device. Bindings of each node
+  depends on the specific driver providing the functionality and
+  properties.
 properties:
   reg:
 maxItems: 1
@@ -85,9 +89,11 @@ patternProperties:
 required:
   - compatible
   - reg
+  - reg-names
   - clocks
   - clock-names
   - interrupts
+  - interrupt-names
   - '#sound-dai-cells'
 
 additionalProperties: false
@@ -134,13 +140,32 @@ allOf:
 then:
   properties:
 clock-names:
-  items:
-- const: pcnoc-sway-clk
-- const: audio-core
-- const: mclk0
-- const: pcnoc-mport-clk
-- const: mi2s-bit-clk0
-- const: mi2s-bit-clk1
+  oneOf:
+   - items:   #for I2S
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: mclk0
+  - const: pcnoc-mport-clk
+  - const: mi2s-bit-clk0
+  - const: mi2s-bit-clk1
+   - items:   #for HDMI
+  - const: pcnoc-sway-clk
+  - const: audio-core
+  - const: pcnoc-mport-clk
+reg-names:
+  anyOf:
+- items:   #for I2S and HDMI
+  - const: lpass-hdmiif
+  - const: lpass-lpaif
+- items:   #for I2S
+  - const: lpass-lpaif
+interrupt-names:
+  anyOf:
+- items:   #for I2S and HDMI
+  - const: lpass-irq-lpaif
+  - const: lpass-irq-hdmi
+- items:   #for I2S
+  - const: lpass-irq-lpaif
   required:
 - iommus
 - power-domains
@@ -152,12 +177,15 @@ examples:
 soc {
 #address-cells = <2>;
 #size-cells = <2>;
-lpass@62f0 {
+lpass@62d8 {
 compatible = "qcom,sc7180-lpass-cpu";
 
-reg = <0 0x62f0  0 0x29000>;
-
-iommus = <&apps_smmu 0x1020 0>;
+reg = <0 0x62d87000 0 0x68000>,
+  <0 0x62f0 0 0x29000>;
+reg-names = "lpass-hdmiif",
+"lpass-lpaif";
+iommus = <&apps_smmu 0x1020 0>,
+ <&apps_smmu 0x1032 0>;
 power-domains = <&lpass_hm 0>;
 
 clocks = <&gcc 131>,
@@ -171,14 +199,16 @@ examples:
   "mclk0", "pcnoc-mport-clk",
   "mi2s-bit-clk0", "mi2s-bit-clk1";
 
-interrupts = <0 160 1>;
-
+interrupts = <0 160 1>,
+ <0 268 1>;
+interrupt-names = "lpass-irq-lpaif",
+  "lpass-irq-hdmi";
 #sound-dai-cells = <1>;
 
 #address-cells = <1>;
 #size-cells = <0>;
 /* Optional to set different MI2S SD lines */
-mi2s-primary@0 {
+dai-link@0 {
 reg = ;
 qcom,playback-sd-lines = <1>;
 qcom,capture-sd-lines = <0>;
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v6 3/5] Asoc:qcom:lpass-cpu:Update dts property read API

[Srinivasa Rao Mandadapu]

From: V Sujith Kumar Reddy 

Signed-off-by: Srinivasa Rao 
Signed-off-by: V Sujith Kumar Reddy 
---
 sound/soc/qcom/lpass-cpu.c  | 2 +-
 sound/soc/qcom/lpass-platform.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/qcom/lpass-cpu.c b/sound/soc/qcom/lpass-cpu.c
index 1ee6d8b..5d84f63 100644
--- a/sound/soc/qcom/lpass-cpu.c
+++ b/sound/soc/qcom/lpass-cpu.c
@@ -575,7 +575,7 @@ int asoc_qcom_lpass_cpu_platform_probe(struct 
platform_device *pdev)
 
of_lpass_cpu_parse_dai_data(dev, drvdata);
 
-   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "lpass-lpaif");
 
drvdata->lpaif = devm_ioremap_resource(dev, res);
if (IS_ERR((void const __force *)drvdata->lpaif)) {
diff --git a/sound/soc/qcom/lpass-platform.c b/sound/soc/qcom/lpass-platform.c
index df692ed..35aead1 100644
--- a/sound/soc/qcom/lpass-platform.c
+++ b/sound/soc/qcom/lpass-platform.c
@@ -638,7 +638,7 @@ int asoc_qcom_lpass_platform_register(struct 
platform_device *pdev)
struct lpass_variant *v = drvdata->variant;
int ret;
 
-   drvdata->lpaif_irq = platform_get_irq(pdev, 0);
+   drvdata->lpaif_irq = platform_get_irq_byname(pdev, "lpass-irq-lpaif");
if (drvdata->lpaif_irq < 0)
return -ENODEV;
 
-- 
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.,
is a member of Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH] sched/deadline: Unthrottle PI boosted threads while enqueuing

[Juri Lelli]

Hi Daniel,

On 16/09/20 09:06, Daniel Bristot de Oliveira wrote:
> stress-ng has a test (stress-ng --cyclic) that creates a set of threads
> under SCHED_DEADLINE with the following parameters:
> 
> dl_runtime   =  1 (10 us)
> dl_deadline  = 10 (100 us)
> dl_period= 10 (100 us)
> 
> These parameters are very aggressive. When using a system without HRTICK
> set, these threads can easily execute longer than the dl_runtime because
> the throttling happens with 1/HZ resolution.
> 
> During the main part of the test, the system works just fine because
> the workload does not try to run over the 10 us. The problem happens at
> the end of the test, on the exit() path. During exit(), the threads need
> to do some cleanups that require real-time mutex locks, mainly those
> related to memory management, resulting in this scenario:
> 
> Note: locks are rt_mutexes...
>  
> TASK A:   TASK B: TASK C:
> activation
>   activation
>   activation
> 
> lock(a): OK!  lock(b): OK!
>   
>   lock(a)
>   -> block (task A owns it)
> -> self notice/set throttled
>  +--<   -> arm replenished timer
>  |switch-out
>  |lock(b)
>  |->  B 
> prio>
>  |-> boost TASK B
>  |  unlock(a) switch-out
>  |  -> handle lock a to B
>  |-> wakeup(B)
>  |  -> B is throttled:
>  |-> do not enqueue
>  | switch-out
>  |
>  |
>  +-> replenishment timer
>   -> TASK B is boosted:
> -> do not enqueue
>  
> 
> BOOM: TASK B is runnable but !enqueued, holding TASK C: the system
> crashes with hung task C.
> 
> This problem is avoided by removing the throttle state from the boosted
> thread while boosting it (by TASK A in the example above), allowing it to
> be queued and run boosted.
> 
> The next replenishment will take care of the runtime overrun, pushing
> the deadline further away. See the "while (dl_se->runtime <= 0)" on
> replenish_dl_entity() for more information.
> 
> Signed-off-by: Daniel Bristot de Oliveira 
> Reported-by: Mark Simmons 
> Reviewed-by: Juri Lelli 
> Tested-by: Mark Simmons 
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: Juri Lelli 
> Cc: Vincent Guittot 
> Cc: Dietmar Eggemann 
> Cc: Steven Rostedt 
> Cc: Ben Segall 
> Cc: Mel Gorman 
> Cc: Daniel Bristot de Oliveira 
> Cc: linux-kernel@vger.kernel.org
> 
> ---

Thanks for this fix.

Acked-by: Juri Lelli 

Best,
Juri

Re: [V9fs-developer] [PATCH 02/13] 9p: Tell the VFS that readpage was synchronous

[Dominique Martinet]

Matthew Wilcox (Oracle) wrote on Thu, Sep 17, 2020:
> diff --git a/fs/9p/vfs_addr.c b/fs/9p/vfs_addr.c
> index cce9ace651a2..506ca0ba2ec7 100644
> --- a/fs/9p/vfs_addr.c
> +++ b/fs/9p/vfs_addr.c
> @@ -280,6 +280,10 @@ static int v9fs_write_begin(struct file *filp, struct 
> address_space *mapping,
>   goto out;
>  
>   retval = v9fs_fid_readpage(v9inode->writeback_fid, page);
> + if (retval == AOP_UPDATED_PAGE) {
> + retval = 0;
> + goto out;
> + }

FWIW this is a change of behaviour; for some reason the code used to
loop back to grab_cache_page_write_begin() and bail out on
PageUptodate() I suppose; some sort of race check?
The whole pattern is a bit weird to me and 9p has no guarantee on
concurrent writes to a file with cache enabled (except that it will
corrupt something), so this part is fine with me.

What I'm curious about is the page used to be both unlocked and put, but
now isn't either and the return value hasn't changed for the caller to
make a difference on write_begin / I don't see any code change in the
vfs  to handle that.
What did I miss?


(FWIW at least cifs in the series has the same pattern change; didn't
check all of them)


Thanks,
-- 
Dominique

Re: [v4] mm: khugepaged: avoid overriding min_free_kbytes set by user

[Michal Hocko]

On Thu 17-09-20 11:16:55, Vijay Balakrishna wrote:
> 
> 
> On 9/17/2020 10:52 AM, Michal Hocko wrote:
> > On Thu 17-09-20 10:27:16, Vijay Balakrishna wrote:
> > > 
> > > 
> > > On 9/17/2020 2:28 AM, Michal Hocko wrote:
> > > > On Wed 16-09-20 23:39:39, Vijay Balakrishna wrote:
> > > > > set_recommended_min_free_kbytes need to honor min_free_kbytes set by 
> > > > > the
> > > > > user.  Post start-of-day THP enable or memory hotplug operations can
> > > > > lose user specified min_free_kbytes, in particular when it is higher 
> > > > > than
> > > > > calculated recommended value.
> > > > 
> > > > I was about to recommend a more detailed explanation when I have
> > > > realized that this patch is not really needed after all. Unless I am
> > > > missing something.
> > > > 
> > > > init_per_zone_wmark_min ignores the newly calculated min_free_kbytes if
> > > > it is lower than user_min_free_kbytes. So calculated min_free_kbytes >=
> > > > user_min_free_kbytes.
> > > > 
> > > > Except for value clamping when the value is reduced and this likely
> > > > needs fixing. But set_recommended_min_free_kbytes should be fine.
> > > > 
> > > 
> > > IIUC, after start-of-day if a user performs
> > > - THP disable
> > > - modifies min_free_bytes
> > > - THP enable
> > > above sequence currently wouldn't result in calling 
> > > init_per_zone_wmark_min.
> > 
> > I will not, but why do you think this matters? All we should care about
> > is that auto-tuning shouldn't reduce user provided value [1] and that
> > the memory hotplug should be consistent with the boot time heuristic.
> > init_per_zone_wmark_min should make sure that the user value is not
> > reduced and thp heuristic makes sure it will not reduce this value.
> > So the property should be transitive with the existing code (modulo the
> > problem I have highlighted).
> > 
> > [1] one could argue that it shouldn't even increase the value strictly
> > speaking because an admin might have a very good reason to decrease the
> > value but this has never been the semantic and changing it now might be
> > problematic
> > 
> 
> I made an attempt to address Kirill A. Shutemov's comment.

This is for Kirill to comment on but my take would be that memory
hotplug really has to alter the user defined min_free_kbytes because it
is manipulating the amount of memory. There are usecases which are
adding a lot of memory.

We are trying to not decrease the value which is arguably a weird semantic
but this is what've been doing for years. We would need to hear a
specific usecase where this matters (e.g. memory hotremove heavy
workalod with manually tuned min_free_kbytes) that misbehaves.

> And incrased
> min_free_kbytes to see the issue in my testing and attempted a fix.  I'm ok
> leaving as it is.  Do not want introduce any changes that may cause
> regression.

I would recommend reposting the patch which adds heuristic for THP (if
THP is enabled) into the hotplug path, arguing with the consistency and
surprising results when adding memory decreases the value. Your initial
problem is in sizing as mentioned in other email thread and you should
be investigating more but this inconsistency might really come as a
surprise.

All that if Kirill is reconsidering his initial position of course.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH 1/4] ARM/omap1: switch to use dma_direct_set_offset for lbus DMA offsets

[Tony Lindgren]

* Christoph Hellwig  [200917 17:37]:
> Switch the omap1510 platform ohci device to use dma_direct_set_offset
> to set the DMA offset instead of using direct hooks into the DMA
> mapping code and remove the now unused hooks.

Looks nice to me :) I still can't test this probably for few more weeks
though but hopefully Aaro or Janusz (Added to Cc) can test it.

Regards,

Tony

> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/include/asm/dma-direct.h | 18 -
>  arch/arm/mach-omap1/include/mach/memory.h | 31 ---
>  arch/arm/mach-omap1/usb.c | 22 
>  3 files changed, 22 insertions(+), 49 deletions(-)
> 
> diff --git a/arch/arm/include/asm/dma-direct.h 
> b/arch/arm/include/asm/dma-direct.h
> index 436544aeb83405..77fcb7ee5ec907 100644
> --- a/arch/arm/include/asm/dma-direct.h
> +++ b/arch/arm/include/asm/dma-direct.h
> @@ -9,7 +9,6 @@
>   * functions used internally by the DMA-mapping API to provide DMA
>   * addresses. They must not be used by drivers.
>   */
> -#ifndef __arch_pfn_to_dma
>  static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
>  {
>   if (dev && dev->dma_range_map)
> @@ -34,23 +33,6 @@ static inline dma_addr_t virt_to_dma(struct device *dev, 
> void *addr)
>   return (dma_addr_t)__virt_to_bus((unsigned long)(addr));
>  }
>  
> -#else
> -static inline dma_addr_t pfn_to_dma(struct device *dev, unsigned long pfn)
> -{
> - return __arch_pfn_to_dma(dev, pfn);
> -}
> -
> -static inline unsigned long dma_to_pfn(struct device *dev, dma_addr_t addr)
> -{
> - return __arch_dma_to_pfn(dev, addr);
> -}
> -
> -static inline dma_addr_t virt_to_dma(struct device *dev, void *addr)
> -{
> - return __arch_virt_to_dma(dev, addr);
> -}
> -#endif
> -
>  static inline dma_addr_t phys_to_dma(struct device *dev, phys_addr_t paddr)
>  {
>   unsigned int offset = paddr & ~PAGE_MASK;
> diff --git a/arch/arm/mach-omap1/include/mach/memory.h 
> b/arch/arm/mach-omap1/include/mach/memory.h
> index 1142560e0078f5..36bccb6ab8 100644
> --- a/arch/arm/mach-omap1/include/mach/memory.h
> +++ b/arch/arm/mach-omap1/include/mach/memory.h
> @@ -14,42 +14,11 @@
>   * OMAP-1510 bus address is translated into a Local Bus address if the
>   * OMAP bus type is lbus. We do the address translation based on the
>   * device overriding the defaults used in the dma-mapping API.
> - * Note that the is_lbus_device() test is not very efficient on 1510
> - * because of the strncmp().
>   */
> -#if defined(CONFIG_ARCH_OMAP15XX) && !defined(__ASSEMBLER__)
>  
>  /*
>   * OMAP-1510 Local Bus address offset
>   */
>  #define OMAP1510_LB_OFFSET   UL(0x3000)
>  
> -#define virt_to_lbus(x)  ((x) - PAGE_OFFSET + OMAP1510_LB_OFFSET)
> -#define lbus_to_virt(x)  ((x) - OMAP1510_LB_OFFSET + PAGE_OFFSET)
> -#define is_lbus_device(dev)  (cpu_is_omap15xx() && dev && 
> (strncmp(dev_name(dev), "ohci", 4) == 0))
> -
> -#define __arch_pfn_to_dma(dev, pfn)  \
> - ({ dma_addr_t __dma = __pfn_to_phys(pfn); \
> -if (is_lbus_device(dev)) \
> - __dma = __dma - PHYS_OFFSET + OMAP1510_LB_OFFSET; \
> -__dma; })
> -
> -#define __arch_dma_to_pfn(dev, addr) \
> - ({ dma_addr_t __dma = addr; \
> -if (is_lbus_device(dev)) \
> - __dma += PHYS_OFFSET - OMAP1510_LB_OFFSET;  \
> -__phys_to_pfn(__dma);\
> - })
> -
> -#define __arch_dma_to_virt(dev, addr)({ (void *) 
> (is_lbus_device(dev) ? \
> - lbus_to_virt(addr) : \
> - __phys_to_virt(addr)); })
> -
> -#define __arch_virt_to_dma(dev, addr)({ unsigned long __addr = 
> (unsigned long)(addr); \
> -(dma_addr_t) (is_lbus_device(dev) ? \
> - virt_to_lbus(__addr) : \
> - __virt_to_phys(__addr)); })
> -
> -#endif   /* CONFIG_ARCH_OMAP15XX */
> -
>  #endif
> diff --git a/arch/arm/mach-omap1/usb.c b/arch/arm/mach-omap1/usb.c
> index d8e9bbda8f7bdd..ba8566204ea9f4 100644
> --- a/arch/arm/mach-omap1/usb.c
> +++ b/arch/arm/mach-omap1/usb.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  
>  #include 
> @@ -542,6 +543,25 @@ static u32 __init omap1_usb2_init(unsigned nwires, 
> unsigned alt_pingroup)
>  /* ULPD_APLL_CTRL */
>  #define APLL_NDPLL_SWITCH(1 << 0)
>  
> +static int omap_1510_usb_ohci_notifier(struct notifier_block *nb,
> + unsigned long event, void *data)
> +{
> + struct device *dev = data;
> +
> + if (event != BUS_NOTIFY_ADD_DEVICE)
> + return NOTIFY_DONE;
> +
> + if (strncmp(dev_name(dev), "ohci", 4) == 0 &&
> + dma_direct_set_offset(dev, PHYS_OFFSET, OMAP1510_LB_OFFSET,
> + (u64)-1))
> +

Re: [PATCH 6/9] f2fs: zstd: Switch to the zstd-1.4.6 API

[Nick Terrell]

> On Sep 17, 2020, at 6:47 PM, Chao Yu  wrote:
> 
> On 2020/9/18 3:34, Nick Terrell wrote:
>>> On Sep 17, 2020, at 11:00 AM, Nick Terrell  wrote:
>>> 
>>> 
>>> 
 On Sep 16, 2020, at 11:31 PM, Chao Yu  wrote:
 
 Hi Nick,
 
 On 2020/9/17 2:39, Nick Terrell wrote:
>> On Sep 15, 2020, at 11:31 PM, Chao Yu  wrote:
>> 
>> Hi Nick,
>> 
>> remove not related mailing list.
>> 
>> On 2020/9/16 11:43, Nick Terrell wrote:
>>> From: Nick Terrell 
>>> Move away from the compatibility wrapper to the zstd-1.4.6 API. This
>>> code is more efficient because it uses the single-pass API instead of
>>> the streaming API. The streaming API is not necessary because the whole
>>> input and output buffers are available. This saves memory because we
>>> don't need to allocate a buffer for the window. It is also more
>>> efficient because it saves unnecessary memcpy calls.
>>> I've had problems testing this code because I see data truncation before
>>> and after this patchset. Help testing this patch would be much
>>> appreciated.
>> 
>> Can you please explain more about data truncation? I'm a little 
>> confused...
>> 
>> Do you mean that f2fs doesn't allocate enough memory for zstd 
>> compression,
>> so that compression is not finished actually, the compressed data is 
>> truncated
>> at dst buffer?
> Hi Chao,
> I’ve tested F2FS using a benchmark I adapted from testing BtrFS [0]. It 
> is possible
> that the script I’m using is buggy or is exposing an edge case in F2FS. 
> The files
> that I copy to F2FS and compress end up truncated with a hole at the end.
 
 Thanks for your explanation. :)
 
> It is based off of upstream commit ab29a807a7.
> E.g. the end of the copied file looks like this, but the original file 
> has non-zero data
> In the end. Until the hole at the end the file is correct.
> od dickens | tail -n 5
>> 46667760 067502 066167 020056 040440 020163 023511 006555 060412
>> 4667 00 00 00 00 00 00 00 00
>> *
>> 46703060 00 00 00 00 00 00 00
>> 46703076
> [0] https://gist.github.com/terrelln/7dd2919937dfbdb8e839e4ad11c81db4
 
 Shouldn't we just get sha1 value by flitering sha1sum output?
 
   asha=`sha1sum $BENCHMARK_DIR/$file |awk {'print $1'}`
   bsha=`sha1sum $MP/$i/$file |awk {'print $1'}`
>>> 
>>> Probably, but it was just a quick one-off script.
>> Ah, never mind, you are right.
 I can't reproduce this issue by using simple data sample, could you share
 that 'dickens' file or other smaller-sized sample if you have?
>>> 
>>> The /tmp/silesia directory in the example is populated with all the files 
>>> from
>>> this website. It is a popular data compression benchmark corpus. You can
>>> click on the “total” link to download a zip archive of all the files.
>>> 
>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__sun.aei.polsl.pl_-7Esdeor_index.php-3Fpage-3Dsilesia&d=DwIDaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=HQM5IQdWOB8WaMoii2dYTw&m=-bYa7TavRodl96xy65hjVIkt5HdMldv4LOCRHJf12n8&s=mdX82rCzyHO-Q3KGJ5b94mqDKcDh1IWEqEWfuqw7P3I&e=
>>>  
>>> -Nick
>> I’ve spent some time minimizing the test case. This script [0] is the 
>> minimized
>> test case that doesn’t require any input files, it builds its own.
>> Several observations:
>> * The input file needs to be 7700481 bytes large, smaller files don’t 
>> trigger the bug.
>> * You have to `chattr +c` the file after copying it otherwise the bug 
>> doesn’t occur.
>> * After `chattr +c` you have to unmount and remount the filesystem to 
>> trigger the bug.
>> I’ve reproduced on v5.9-rc5 (856deb866d16e). I’ve also reproduced on my host 
>> machine
>> running 5.8.5-arch1-1.
>> [0] https://gist.github.com/terrelln/4bba325abdfa3a6f014e9911ac92a185
> 
> Ah, I got it.
> 
> Step of enabling compressed inode is not correct, we should touch an empty 
> file, and
> then use 'chattr +c' on that file to enable compression, otherwise the race 
> condition
> could be complicated to handle. So we need below diff to disallow setting 
> compression
> flag on an non-empty file:

Yup, that did the trick. After that change I was able to successfully test 
F2FS. I found
a bug in my compatibility wrappers, so I’m going to be sending a V2 that fixes 
it.

I’ll include these numbers in my next commit message, but with these changes 
F2FS
decompression memory usage drops from 1.4 MB to 160 KB. Decompression speeds
up 20% in total from the entire series, and compression speeds up 8%.

Thanks for the help debugging,
Nick

> diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> index 8a422400e824..b462db7898fd 100644
> --- a/fs/f2fs/file.c
> +++ b/fs/f2fs/file.c
> @@ -1836,6 +1836,8 @@ static int f2fs_setflags_common(struct inode *inode, 
> u32 iflags, u32 mask)
>   if (iflags & F2FS_COMPR

Re: [PATCH v4 0/7] HWpoison: further fixes and cleanups

[osalvador]

On 2020-09-17 17:27, HORIGUCHI NAOYA wrote:
Sorry, I modified the patches based on the different assumption from 
yours.

I firstly thought of taking page off after confirming the error page
is freed back to buddy. This approach leaves the possibility of reusing
the error page (which is acceptable), but simpler and less invasive 
one.


Your approach removes the error page from page allocator's control in
freeing time. It has no possibility of reusing the error page but 
changes

are tightly coupled with page free code.

This is a tradeoff between complexity and completeness of soft offline,
Now I'm not sure I could persist on my own opinion without providing
working code, and it's OK for me to take your one.


Yeah, you are right it is a trade off.
I would suggest taking this path now, and if it proofs to be problematic 
in some way, we can always

do the:

free_page
 take_it_off_buddy
  OK: mark it as hwpoison and increment refcount
  NOT_OK (raced with allocation): oops, sorry


The test passed in my environment, so this is fine.


Thanks for trying it out.



If they do, I will try to see if Andrew can squezee above changes into 
[1],

where they belong to.


Yes, proposing the fix for 
mmhwpoison-rework-soft-offline-for-in-use-pages.patch

seems fine to me.

Again, sorry for modifying code without asking.


No worries, I wil do a couple of tests on my own and then I will talk to 
Andrew to see if we can squeeze the changes in there.

Re: [PATCH v2] dt-bindings: mfd: rohm,bd71837-pmic: Add common properties

[Vaittinen, Matti]

Hi d Ho peeps!

On Thu, 2020-09-17 at 21:37 +0200, Krzysztof Kozlowski wrote:
> Add common properties appearing in DTSes (clock-names,
> clock-output-names) with the common values (actually used in DTSes)
> to
> fix dtbs_check warnings like:
> 
>   arch/arm64/boot/dts/freescale/imx8mq-librem5-r2.dt.yaml:
> pmic@4b: 'clock-names', 'clock-output-names', do not match any of
> the regexes: 'pinctrl-[0-9]+'
> 
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> Changes since v1:
> 1. Define the names, as used in existing DTS files.
> ---
>  .../devicetree/bindings/mfd/rohm,bd71837-pmic.yaml  | 6
> ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> pmic.yaml b/Documentation/devicetree/bindings/mfd/rohm,bd71837-
> pmic.yaml
> index 65018a019e1d..3bfdd33702ad 100644
> --- a/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> +++ b/Documentation/devicetree/bindings/mfd/rohm,bd71837-pmic.yaml
> @@ -32,9 +32,15 @@ properties:
>clocks:
>  maxItems: 1
>  
> +  clock-names:
> +const: osc

I guess existing board dtses use "osc" then? Ok.

>"#clock-cells":
>  const: 0
>  
> +  clock-output-names:
> +const: pmic_clk

This is not a strong opinion but I feel that pmic_clk is a bit too
generic name? I mean, what if there is a system with more than one
PMICs? (I don't see such use-case with the BD718x7 though - but perhaps
this can serve as a misleading example for other PMICs? For example
with the ROHM BD96801 family there may be multiple PMICs in one
system). Anyways - if Rob is happy with this then please go with it :)

Acked-By: Matti Vaittinen 
 * 
Thanks again for improving these bindings! I am constantly struggling
with these x_x. Writing the bindings is probably hardest part of PMIC
driver development -_-;

[PATCH v2] dm: Call proper helper to determine dax support

[Dan Williams]

From: Jan Kara 

DM was calling generic_fsdax_supported() to determine whether a device
referenced in the DM table supports DAX. However this is a helper for "leaf" 
device drivers so that
they don't have to duplicate common generic checks. High level code
should call dax_supported() helper which that calls into appropriate
helper for the particular device. This problem manifested itself as
kernel messages:

dm-3: error: dax access failed (-95)

when lvm2-testsuite run in cases where a DM device was stacked on top of
another DM device.

Fixes: 7bf7eac8d648 ("dax: Arrange for dax_supported check to span multiple 
devices")
Cc: 
Tested-by: Adrian Huang 
Signed-off-by: Jan Kara 
Acked-by: Mike Snitzer 
Signed-off-by: Dan Williams 
---
Changes since v1 [1]:
- Add missing dax_read_lock() around dax_supported()

[1]: http://lore.kernel.org/r/20200916151445.450-1-j...@suse.cz

 drivers/dax/super.c   |4 
 drivers/md/dm-table.c |   10 +++---
 include/linux/dax.h   |   11 +--
 3 files changed, 20 insertions(+), 5 deletions(-)

diff --git a/drivers/dax/super.c b/drivers/dax/super.c
index e5767c83ea23..b6284c5cae0a 100644
--- a/drivers/dax/super.c
+++ b/drivers/dax/super.c
@@ -325,11 +325,15 @@ EXPORT_SYMBOL_GPL(dax_direct_access);
 bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev,
int blocksize, sector_t start, sector_t len)
 {
+   if (!dax_dev)
+   return false;
+
if (!dax_alive(dax_dev))
return false;
 
return dax_dev->ops->dax_supported(dax_dev, bdev, blocksize, start, 
len);
 }
+EXPORT_SYMBOL_GPL(dax_supported);
 
 size_t dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, void 
*addr,
size_t bytes, struct iov_iter *i)
diff --git a/drivers/md/dm-table.c b/drivers/md/dm-table.c
index 5edc3079e7c1..229f461e7def 100644
--- a/drivers/md/dm-table.c
+++ b/drivers/md/dm-table.c
@@ -860,10 +860,14 @@ EXPORT_SYMBOL_GPL(dm_table_set_type);
 int device_supports_dax(struct dm_target *ti, struct dm_dev *dev,
sector_t start, sector_t len, void *data)
 {
-   int blocksize = *(int *) data;
+   int blocksize = *(int *) data, id;
+   bool rc;
 
-   return generic_fsdax_supported(dev->dax_dev, dev->bdev, blocksize,
-  start, len);
+   id = dax_read_lock();
+   rc = dax_supported(dev->dax_dev, dev->bdev, blocksize, start, len);
+   dax_read_unlock(id);
+
+   return rc;
 }
 
 /* Check devices support synchronous DAX */
diff --git a/include/linux/dax.h b/include/linux/dax.h
index 6904d4e0b2e0..9f916326814a 100644
--- a/include/linux/dax.h
+++ b/include/linux/dax.h
@@ -130,6 +130,8 @@ static inline bool generic_fsdax_supported(struct 
dax_device *dax_dev,
return __generic_fsdax_supported(dax_dev, bdev, blocksize, start,
sectors);
 }
+bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev,
+   int blocksize, sector_t start, sector_t len);
 
 static inline void fs_put_dax(struct dax_device *dax_dev)
 {
@@ -157,6 +159,13 @@ static inline bool generic_fsdax_supported(struct 
dax_device *dax_dev,
return false;
 }
 
+static inline bool dax_supported(struct dax_device *dax_dev,
+   struct block_device *bdev, int blocksize, sector_t start,
+   sector_t len)
+{
+   return false;
+}
+
 static inline void fs_put_dax(struct dax_device *dax_dev)
 {
 }
@@ -195,8 +204,6 @@ bool dax_alive(struct dax_device *dax_dev);
 void *dax_get_private(struct dax_device *dax_dev);
 long dax_direct_access(struct dax_device *dax_dev, pgoff_t pgoff, long 
nr_pages,
void **kaddr, pfn_t *pfn);
-bool dax_supported(struct dax_device *dax_dev, struct block_device *bdev,
-   int blocksize, sector_t start, sector_t len);
 size_t dax_copy_from_iter(struct dax_device *dax_dev, pgoff_t pgoff, void 
*addr,
size_t bytes, struct iov_iter *i);
 size_t dax_copy_to_iter(struct dax_device *dax_dev, pgoff_t pgoff, void *addr,

[PATCH] Documentation/admin-guide: kernel-parameters: fix "disable_ddw" wording

[Randy Dunlap]

Drop and extraneous word (if) in a sentence.

Signed-off-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200917.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20200917/Documentation/admin-guide/kernel-parameters.txt
@@ -951,7 +951,7 @@
Arch Perfmon v4 (Skylake and newer).
 
disable_ddw [PPC/PSERIES]
-   Disable Dynamic DMA Window support. Use this if
+   Disable Dynamic DMA Window support. Use this
to workaround buggy firmware.
 
disable_ipv6=   [IPV6]

[PATCH] Documentation/admin-guide: kernel-parameters: fix "io7" parameter description

[Randy Dunlap]

Fix punctuation and capitalization for the "io7" boot parameter.

Signed-off-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200917.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20200917/Documentation/admin-guide/kernel-parameters.txt
@@ -1973,7 +1973,7 @@
1 - Bypass the IOMMU for DMA.
unset - Use value of CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
 
-   io7=[HW] IO7 for Marvel based alpha systems
+   io7=[HW] IO7 for Marvel-based Alpha systems
See comment before marvel_specify_io7 in
arch/alpha/kernel/core_marvel.c.
 

[PATCH] Documentation/admin-guide: kernel-parameters: capitalize Korina

[Randy Dunlap]

Fix typo, capitalize Korina proper noun.

Signed-off-by: Randy Dunlap 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-next-20200917.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20200917/Documentation/admin-guide/kernel-parameters.txt
@@ -2194,7 +2194,7 @@
kgdbwait[KGDB] Stop kernel execution and enter the
kernel debugger at the earliest opportunity.
 
-   kmac=   [MIPS] korina ethernet MAC address.
+   kmac=   [MIPS] Korina ethernet MAC address.
Configure the RouterBoard 532 series on-chip
Ethernet adapter MAC address.
 

[PATCH] Documentation: admin-guide: kernel-parameters: reformat "lapic=" boot option

[Randy Dunlap]

Reformat "lapic=" to try to make it more understandable and similar
to the style that is mostly used in this file.

Signed-off-by: Randy Dunlap 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20200917.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20200917/Documentation/admin-guide/kernel-parameters.txt
@@ -2384,9 +2384,10 @@
lapic   [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
 
-   lapic=  [X86,APIC] "notscdeadline" Do not use TSC deadline
+   lapic=  [X86,APIC] Do not use TSC deadline
value for LAPIC timer one-shot implementation. Default
back to the programmable timer unit in the LAPIC.
+   Format: notscdeadline
 
lapic_timer_c2_ok   [X86,APIC] trust the local apic timer
in C2 power state.

Re: [PATCH v1 4/6] wdt: Support wdt on ROHM BD9576MUF and BD9573MUF

[Guenter Roeck]

On 9/17/20 1:03 AM, Matti Vaittinen wrote:
> Add Watchdog support for ROHM BD9576MUF and BD9573MUF PMICs which are
> mainly used to power the R-Car series processors. The watchdog is
> pinged using a GPIO and enabled using another GPIO. Additionally
> watchdog time-out can be configured to HW prior starting the watchdog.
> Watchdog timeout can be configured to detect only delayed ping or in
> a window mode where also too fast pings are detected.
> 
> Signed-off-by: Matti Vaittinen 
> ---
>  drivers/watchdog/Kconfig  |  13 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/bd9576_wdt.c | 295 ++
>  3 files changed, 309 insertions(+)
>  create mode 100644 drivers/watchdog/bd9576_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index ab7aad5a1e69..d042a517a946 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -172,6 +172,19 @@ config BD70528_WATCHDOG
> Alternatively say M to compile the driver as a module,
> which will be called bd70528_wdt.
>  
> +config BD957XMUF_WATCHDOG
> + tristate "ROHM BD9576MUF and BD9573MUF PMIC Watchdog"
> + depends on MFD_ROHM_BD957XMUF
> + select WATCHDOG_CORE
> + help
> +   Support for the watchdog in the ROHM BD9576 and BD9573 PMICs.
> +   These PMIC ICs contain watchdog block which can be configured
> +   to toggle reset line if SoC fails to ping watchdog via GPIO.
> +
> +   Say Y here to include support for the ROHM BD9576 or BD9573
> +   watchdog. Alternatively say M to compile the driver as a module,
> +   which will be called bd9576_wdt.
> +
>  config DA9052_WATCHDOG
>   tristate "Dialog DA9052 Watchdog"
>   depends on PMIC_DA9052 || COMPILE_TEST
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index 97bed1d3d97c..14d75f98e3df 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -208,6 +208,7 @@ obj-$(CONFIG_XEN_WDT) += xen_wdt.o
>  
>  # Architecture Independent
>  obj-$(CONFIG_BD70528_WATCHDOG) += bd70528_wdt.o
> +obj-$(CONFIG_BD957XMUF_WATCHDOG) += bd9576_wdt.o
>  obj-$(CONFIG_DA9052_WATCHDOG) += da9052_wdt.o
>  obj-$(CONFIG_DA9055_WATCHDOG) += da9055_wdt.o
>  obj-$(CONFIG_DA9062_WATCHDOG) += da9062_wdt.o
> diff --git a/drivers/watchdog/bd9576_wdt.c b/drivers/watchdog/bd9576_wdt.c
> new file mode 100644
> index ..917c8c7ddeb1
> --- /dev/null
> +++ b/drivers/watchdog/bd9576_wdt.c
> @@ -0,0 +1,295 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 ROHM Semiconductors
> + *
> + * ROHM BD9576MUF and BD9573MUF Watchdog driver
> + */
> +
> +#include 
> +#include 

Alphabetic include file order please.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static bool nowayout;
> +module_param(nowayout, bool, 0);
> +MODULE_PARM_DESC(nowayout,
> + "Watchdog cannot be stopped once started (default=\"false\")");
> +
> +#define HW_MARGIN_MIN 2
> +#define HW_MARGIN_MAX 4416
> +#define BD957X_WDT_DEFAULT_MARGIN 4416
> +
> +struct bd9576_wdt_priv {
> + struct gpio_desc*gpiod_ping;
> + struct gpio_desc*gpiod_en;
> + struct device   *dev;
> + struct regmap   *regmap;
> + boolalways_running;
> + struct watchdog_device  wdd;
> +};
> +
> +static void bd9576_wdt_disable(struct bd9576_wdt_priv *priv)
> +{
> + gpiod_set_value_cansleep(priv->gpiod_en, 0);
> +}
> +
> +static int bd9576_wdt_ping(struct watchdog_device *wdd)
> +{
> + struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
> +
> + /* Pulse */
> + gpiod_set_value_cansleep(priv->gpiod_ping, 1);
> + gpiod_set_value_cansleep(priv->gpiod_ping, 0);
> +
> + return 0;
> +}
> +
> +static int bd9576_wdt_start(struct watchdog_device *wdd)
> +{
> + struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
> +
> + gpiod_set_value_cansleep(priv->gpiod_en, 1);
> +
> + return bd9576_wdt_ping(wdd);
> +}
> +
> +static int bd9576_wdt_stop(struct watchdog_device *wdd)
> +{
> + struct bd9576_wdt_priv *priv = watchdog_get_drvdata(wdd);
> +
> + if (!priv->always_running)
> + bd9576_wdt_disable(priv);
> + else
> + set_bit(WDOG_HW_RUNNING, &wdd->status);
> +
> + return 0;
> +}
> +
> +static const struct watchdog_info bd957x_wdt_ident = {
> + .options= WDIOF_MAGICCLOSE | WDIOF_KEEPALIVEPING |
> +   WDIOF_SETTIMEOUT,
> + .identity   = "BD957x Watchdog",
> +};
> +
> +static const struct watchdog_ops bd957x_wdt_ops = {
> + .owner  = THIS_MODULE,
> + .start  = bd9576_wdt_start,
> + .stop   = bd9576_wdt_stop,
> + .ping   = bd9576_wdt_ping,
> +};
> +
> +/* Unit is hundreds of uS */
> +#define FASTNG_MIN 23
> +
> +static int find_closest_fast(int target, int *sel, int *val)
> +{
> + int i;
> + int window = 

Re: [[PATCH]] mm: khugepaged: recalculate min_free_kbytes after memory hotplug as expected by khugepaged

[Michal Hocko]

On Thu 17-09-20 11:03:56, Vijay Balakrishna wrote:
[...]
> > > The auto tuned value is incorrect post hotplug memory operation, in our 
> > > use
> > > case memoy hot add occurs very early during boot.
> > Define incorrect. What are the actual values? Have you tried to increase
> > the value manually after the hotplug?
> 
> In our case SoC with 8GB memory, system tuned min_free_kbytes
> - first to 22528
> - we perform memory hot add very early in boot

What was the original and after-the-hotplug size of memory and layout?
I suspect that all the hotplugged memory is in Movable zone, right?

> - now min_free_kbytes is 8703
> 
> Before looking at code, first I manually restored min_free_kbytes soon after
> boot, reran stress and didn't notice symptoms I mentioned in change log.

This is really surprising and I strongly suspect that an earlier reclaim
just changed the timing enough so that workload has spread the memory
prpessure over a longer time and that might have been enough to recycle
some of the unreclaimable memory due to its natural life time. But this
is a pure speculation. Much more data would be needed to analyze this.

In any case your stress test is oveprovisioning your Normal zone and
increased min_free_kbytes just papers over the sizing problem.
-- 
Michal Hocko
SUSE Labs

Re: linux-next: manual merge of the staging tree with the crypto tree

[Herbert Xu]

On Fri, Sep 18, 2020 at 03:21:27PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the staging tree got a conflict in:
> 
>   drivers/staging/rtl8192e/Kconfig
> 
> between commit:
> 
>   054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")
> 
> from the crypto tree and commits:
> 
>   243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for 
> RTLLIB_CRYPTO_TKIP")
>   02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for 
> RTLLIB_CRYPTO_WEP")
> 
> from the staging tree.

Those two commits should just be dropped.
 
> diff --cc drivers/staging/rtl8192e/Kconfig
> index 4c440bdaaf6e,31e076cc6f16..
> --- a/drivers/staging/rtl8192e/Kconfig
> +++ b/drivers/staging/rtl8192e/Kconfig
> @@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
>   config RTLLIB_CRYPTO_TKIP
>   tristate "Support for rtllib TKIP crypto"
>   depends on RTLLIB
> + select CRYPTO
>  -select CRYPTO_ARC4
>  +select CRYPTO_LIB_ARC4

As the driver has been converted over to the lib arc4 API, it
does not need to select CRYPTO at all.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: [PATCH] objtool: ignore unreachable trap after call to noreturn functions

[Ilie Halip]

> The patch looks good to me.  Which versions of Clang do the trap after
> noreturn call?  It would be good to have that in the commit message.

I omitted this because it happens with all versions of clang that are
supported for building the kernel. clang-9 is the oldest version that
could build the mainline x86_64 kernel right now, and it has the same
behavior.

Should I send a v2 with this info?

I.H.

Re: [PATCH 3/3] hwmon: (lm75) Add regulator support

[Guenter Roeck]

On 9/17/20 3:18 AM, Alban Bedel wrote:
> Add regulator support for boards where the sensor first need to be
> powered up before it can be used.
> 
> Signed-off-by: Alban Bedel 
> ---
>  drivers/hwmon/lm75.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/hwmon/lm75.c b/drivers/hwmon/lm75.c
> index ba0be48aeadd..b673f8d2ef20 100644
> --- a/drivers/hwmon/lm75.c
> +++ b/drivers/hwmon/lm75.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "lm75.h"
>  
>  /*
> @@ -101,6 +102,7 @@ static const unsigned short normal_i2c[] = { 0x48, 0x49, 
> 0x4a, 0x4b, 0x4c,
>  struct lm75_data {
>   struct i2c_client   *client;
>   struct regmap   *regmap;
> + struct regulator*vs;
>   u8  orig_conf;
>   u8  current_conf;
>   u8  resolution; /* In bits, 9 to 16 */
> @@ -540,6 +542,8 @@ static void lm75_remove(void *data)
>   struct i2c_client *client = lm75->client;
>  
>   i2c_smbus_write_byte_data(client, LM75_REG_CONF, lm75->orig_conf);
> + if (lm75->vs)
> + regulator_disable(lm75->vs);
>  }
>  
>  static int
> @@ -567,6 +571,14 @@ lm75_probe(struct i2c_client *client, const struct 
> i2c_device_id *id)
>   data->client = client;
>   data->kind = kind;
>  
> + data->vs = devm_regulator_get_optional(dev, "vs");

Looking into the regulator API, it may be better if you use 
devm_regulator_get().
AFAICS it returns a dummy regulator if there is none, and NULL if the regulator
subsystem is disabled. So
data->vs = devm_regulator_get(dev, "vs");
if (IS_ERR(data->vs))
return PTR_ERR(data->vs);
should work and would be less messy.

> + if (IS_ERR(data->vs)) {
> + if (PTR_ERR(data->vs) == -ENODEV)
> + data->vs = NULL;
> + else
> + return PTR_ERR(data->vs);
> + }
> +
>   data->regmap = devm_regmap_init_i2c(client, &lm75_regmap_config);
>   if (IS_ERR(data->regmap))
>   return PTR_ERR(data->regmap);
> @@ -581,11 +593,21 @@ lm75_probe(struct i2c_client *client, const struct 
> i2c_device_id *id)
>   data->sample_time = data->params->default_sample_time;
>   data->resolution = data->params->default_resolution;
>  
> + /* Enable the power */
> + if (data->vs) {
> + err = regulator_enable(data->vs);
> + if (err) {
> + dev_err(dev, "failed to enable regulator: %d\n", err);
> + return err;
> + }
> + }
> +

How about device removal ? Don't you have to call regulator_disable()
there as well ? If so, it might be best to use devm_add_action_or_reset()
to register a disable function.

Thanks,
Guenter

>   /* Cache original configuration */
>   status = i2c_smbus_read_byte_data(client, LM75_REG_CONF);
>   if (status < 0) {
>   dev_dbg(dev, "Can't read config? %d\n", status);
> - return status;
> + err = status;
> + goto disable_regulator;
>   }
>   data->orig_conf = status;
>   data->current_conf = status;
> @@ -593,7 +615,7 @@ lm75_probe(struct i2c_client *client, const struct 
> i2c_device_id *id)
>   err = lm75_write_config(data, data->params->set_mask,
>   data->params->clr_mask);
>   if (err)
> - return err;
> + goto disable_regulator;
>  
>   err = devm_add_action_or_reset(dev, lm75_remove, data);
>   if (err)
> @@ -608,6 +630,11 @@ lm75_probe(struct i2c_client *client, const struct 
> i2c_device_id *id)
>   dev_info(dev, "%s: sensor '%s'\n", dev_name(hwmon_dev), client->name);
>  
>   return 0;
> +
> +disable_regulator:
> + if (data->vs)
> + regulator_disable(data->vs);
> + return err;
>  }
>  
>  static const struct i2c_device_id lm75_ids[] = {
> 

Re: [PATCH v12 3/9] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel[_low]()

[Dave Young]

On 09/18/20 at 11:57am, chenzhou wrote:
> Hi Dave,
> 
> 
> On 2020/9/18 11:01, Dave Young wrote:
> > On 09/07/20 at 09:47pm, Chen Zhou wrote:
> >> To make the functions reserve_crashkernel[_low]() as generic,
> >> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
> >>
> >> Signed-off-by: Chen Zhou 
> >> ---
> >>  arch/x86/kernel/setup.c | 11 ++-
> >>  1 file changed, 6 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
> >> index d7fd90c52dae..71a6a6e7ca5b 100644
> >> --- a/arch/x86/kernel/setup.c
> >> +++ b/arch/x86/kernel/setup.c
> >> @@ -430,7 +430,7 @@ static int __init reserve_crashkernel_low(void)
> >>unsigned long total_low_mem;
> >>int ret;
> >>  
> >> -  total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
> >> +  total_low_mem = memblock_mem_size(CRASH_ADDR_LOW_MAX >> PAGE_SHIFT);
> > total_low_mem != CRASH_ADDR_LOW_MAX
> I just replace the magic number with macro, no other change.
> Besides, function memblock_mem_size(limit_pfn) will compute the memory size
> according to the actual system ram.
> 

Ok, it is not obvious in patch this is 64bit only, I'm fine with this
then.

Re: [PATCH 2/2] dt-bindings: phy: cdns,torrent-phy: add reset-names

[Vinod Koul]

On 16-09-20, 15:47, Tomi Valkeinen wrote:
> Add reset-names as a required property.
> 
> There are no dts files using torrent phy yet, so it is safe to add a new
> required property.
> 
> Signed-off-by: Tomi Valkeinen 
> ---
>  .../devicetree/bindings/phy/phy-cadence-torrent.yaml | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml 
> b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> index 4071438be2ba..12ce022e4764 100644
> --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml
> @@ -54,6 +54,10 @@ properties:
>Torrent PHY reset.
>See Documentation/devicetree/bindings/reset/reset.txt
>  
> +  reset-names:
> +items:
> +  - const: torrent_reset
> +
>  patternProperties:
>'^phy@[0-7]+$':
>  type: object
> @@ -111,6 +115,7 @@ required:
>- reg
>- reg-names
>- resets
> +  - reset-names

Update the example as well please.
>  
>  additionalProperties: false
>  
> -- 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

-- 
~Vinod

linux-next: manual merge of the staging tree with the crypto tree

[Stephen Rothwell]

Hi all,

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

  drivers/staging/rtl8192e/Kconfig

between commit:

  054694a46d64 ("staging/rtl8192e: switch to RC4 library interface")

from the crypto tree and commits:

  243d040a6e4a ("staging: rtl8192e: fix kconfig dependency warning for 
RTLLIB_CRYPTO_TKIP")
  02c4260713d6 ("staging: rtl8192e: fix kconfig dependency warning for 
RTLLIB_CRYPTO_WEP")

from the staging tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/staging/rtl8192e/Kconfig
index 4c440bdaaf6e,31e076cc6f16..
--- a/drivers/staging/rtl8192e/Kconfig
+++ b/drivers/staging/rtl8192e/Kconfig
@@@ -25,7 -26,8 +26,8 @@@ config RTLLIB_CRYPTO_CCM
  config RTLLIB_CRYPTO_TKIP
tristate "Support for rtllib TKIP crypto"
depends on RTLLIB
+   select CRYPTO
 -  select CRYPTO_ARC4
 +  select CRYPTO_LIB_ARC4
select CRYPTO_MICHAEL_MIC
default y
help
@@@ -35,7 -37,8 +37,8 @@@
  
  config RTLLIB_CRYPTO_WEP
tristate "Support for rtllib WEP crypto"
+   select CRYPTO
 -  select CRYPTO_ARC4
 +  select CRYPTO_LIB_ARC4
depends on RTLLIB
default y
help


pgpgUf9iA05fD.pgp
Description: OpenPGP digital signature

Re: [PATCH v3 00/13] PHY: Add support for multilink configurations in Cadence Torrent PHY driver

[Vinod Koul]

On 17-09-20, 09:30, Swapnil Jakhade wrote:
> Cadence Torrent PHY is a multiprotocol PHY supporting different multilink
> PHY configurations including DisplayPort, PCIe, USB, SGMII, QSGMII etc.
> This patch series extends functionality of Torrent PHY driver to support
> following configurations:
> - Single link PCIe configuration
> - PCIe + SGMII/QSGMII Unique SSC multilink configuration
> - Single link SGMII/QSGMII configuration
> - Single link USB configuration
> - PCIe + USB Unique SSC multilink configuration
> - USB + SGMII/QSGMII multilink configuration
> 
> The changes have been validated on TI J7200 platform.

Applied, thanks

-- 
~Vinod

Re: [PATCH 3/4] ARM/dma-mapping: don't handle NULL devices in dma-direct.h

[Christoph Hellwig]

On Thu, Sep 17, 2020 at 07:50:10PM +0100, Russell King - ARM Linux admin wrote:
> On Thu, Sep 17, 2020 at 07:32:28PM +0200, Christoph Hellwig wrote:
> > The DMA API removed support for not passing in a device a long time
> > ago, so remove the NULL checks.
> 
> What happens with ISA devices?

For actual drivers they've been switched to struct isa_driver, which
provides a struct device.  For some of the special case like the
arch/arm/kernel/dma-isa.c we now use static struct device instances.

[PATCH] Documentation: admin-guide: reformat "lapic=" boot option

[Randy Dunlap]

Reformat "lapic=" to try to make it more understandable and similar
to the style that is mostly used in this file.

Signed-off-by: Randy Dunlap 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: linux-...@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-next-20200917.orig/Documentation/admin-guide/kernel-parameters.txt
+++ linux-next-20200917/Documentation/admin-guide/kernel-parameters.txt
@@ -2384,9 +2384,10 @@
lapic   [X86-32,APIC] Enable the local APIC even if BIOS
disabled it.
 
-   lapic=  [X86,APIC] "notscdeadline" Do not use TSC deadline
+   lapic=  [X86,APIC] Do not use TSC deadline
value for LAPIC timer one-shot implementation. Default
back to the programmable timer unit in the LAPIC.
+   Format: notscdeadline
 
lapic_timer_c2_ok   [X86,APIC] trust the local apic timer
in C2 power state.

[PATCHv3 0/1] Optimize ext4 file overwrites - perf improvement

[Ritesh Harjani]

Hello,

v2 -> v3
1. Switched to suggested approach from Jan to make the approach general
for all file writes rather than only for DAX.
(So as of now both DAX & DIO should benefit from this as both uses the same
iomap path. Although note that I only tested performance improvement for DAX)

Gave a run on xfstests with -g quick,dax and didn't observe any new
issues with this patch.

In case of file writes, currently we start a journal txn irrespective of whether
it's an overwrite or not. In case of an overwrite we don't need to start a
jbd2 txn since the blocks are already allocated.
So this patch optimizes away the txn start in case of file (DAX/DIO) overwrites.
This could significantly boost performance for multi-threaded writes
specially random writes (overwrite).
Fio script used to collect perf numbers is mentioned below.

Below numbers were calculated on a QEMU setup on ppc64 box with simulated
pmem (fsdax) device. 

Didn't observe any new failures with this patch in xfstests "-g quick,dax"

Performance numbers with different threads - (~10x improvement)
==

vanilla_kernel(kIOPS) (randomwrite)
 60 +-+--+---++++---+--+-+   
 |+   +++**  +   +|   
  55 +-+ ** +-+   
 |  **   **   |   
 |  **   **   |   
  50 +-+**   ** +-+   
 |  **   **   |   
  45 +-+**   ** +-+   
 |  **   **   |   
 |  **   **   |   
  40 +-+**   ** +-+   
 |  **   **   |   
  35 +-+   **   **   ** +-+   
 | **   **   **   **  |   
 | **   **   **  **   **  |   
  30 +-+  **   **   **   **  **   **+-+   
 |**  +**  +**  +**  **  +**  |   
  25 +-+--**--+**--+**--+**--**--+**+-+   
  1   248   12  16
 Threads   
patched_kernel(kIOPS) (randomwrite)
  600 +-+-+++---++---+--+-+   
  |   +++   ++   +**  |   
  |   **  |   
  500 +-+ **+-+   
  |   **  |   
  |   **  **  |   
  400 +-+ **  **+-+   
  |   **  **  |   
  300 +-+**   **  **+-+   
  |  **   **  **  |   
  |  **   **  **  |   
  200 +-+**   **  **+-+   
  | **   **   **  **  |   
  | **   **   **  **  |   
  100 +-+   **  **   **   **  **+-+   
  | **  **   **   **  **  |   
  |   +**  +**  **  +**  +** +**  |   
0 +-+-+**--+**--**--+**--+**-+**+-+   
  124   8   12  16
Threads   
fio script
==
[global]
rw=randwrite
norandommap=1
invalidate=0
bs=4k
numjobs=16  --> changed this for different thread options
time_based=1
ramp_time=30
runtime=60
group_reporting=1
ioengine=psync
direct=1
size=16G
filename=file1.0.0:file1.0.1:file1.0.2:file1.0.3:file1.0.4:file1.0.5:file1.0.6:file1.0.7:file1.0.8:file1.0.9:file1.0.10:file1.0.11:file1.0.12:file1.0.13:file1.0.14:file1.0.15:file1.0.16:file1.0.17:file1.0.18:file1.0.19:file1.0.20:file1.0.21:file1.0.22:file1.0.23:file1.0.24:file1.0.25:file1.0.26:file1.0.27:file1.0.28:file1.0.29:file1.0.30:file1.0.31
file_service_type=random
nrfiles=32
directory=/mnt/

[name]
directory=/mnt/
direct=1

NOTE:
==
1. Looking at ~10x perf delta, I probed a bit deeper to understand what's 
causing
this scalability problem. It seems when we are starting a jbd2 txn then slab
alloc code is observing some serious contention around spinlock.

I think that the spinlock contention proble

[PATCHv3 1/1] ext4: Optimize file overwrites

[Ritesh Harjani]

In case if the file already has underlying blocks/extents allocated
then we don't need to start a journal txn and can directly return
the underlying mapping. Currently ext4_iomap_begin() is used by
both DAX & DIO path. We can check if the write request is an
overwrite & then directly return the mapping information.

This could give a significant perf boost for multi-threaded writes
specially random overwrites.
On PPC64 VM with simulated pmem(DAX) device, ~10x perf improvement
could be seen in random writes (overwrite). Also bcoz this optimizes
away the spinlock contention during jbd2 slab cache allocation
(jbd2_journal_handle). On x86 VM, ~2x perf improvement was observed.

Reported-by: Dan Williams 
Suggested-by: Jan Kara 
Signed-off-by: Ritesh Harjani 
---
 fs/ext4/inode.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 10dd470876b3..6eae17758ece 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3437,14 +3437,26 @@ static int ext4_iomap_begin(struct inode *inode, loff_t 
offset, loff_t length,
map.m_len = min_t(loff_t, (offset + length - 1) >> blkbits,
  EXT4_MAX_LOGICAL_BLOCK) - map.m_lblk + 1;
 
-   if (flags & IOMAP_WRITE)
+   if (flags & IOMAP_WRITE) {
+   /*
+* We check here if the blocks are already allocated, then we
+* don't need to start a journal txn and we can directly return
+* the mapping information. This could boost performance
+* especially in multi-threaded overwrite requests.
+*/
+   if (offset + length <= i_size_read(inode)) {
+   ret = ext4_map_blocks(NULL, inode, &map, 0);
+   if (ret > 0 && (map.m_flags & EXT4_MAP_MAPPED))
+   goto out;
+   }
ret = ext4_iomap_alloc(inode, &map, flags);
-   else
+   } else {
ret = ext4_map_blocks(NULL, inode, &map, 0);
+   }
 
if (ret < 0)
return ret;
-
+out:
ext4_set_iomap(inode, iomap, &map, offset, length);
 
return 0;
-- 
2.26.2

Re: [PATCH v3 0/7] PHY: Prepare Cadence Torrent PHY driver to support multilink configurations

[Vinod Koul]

On 16-09-20, 20:28, Swapnil Jakhade wrote:
> Cadence Torrent PHY is a multiprotocol PHY supporting different multilink
> PHY configurations including DisplayPort, PCIe, USB, SGMII, QSGMII etc.
> Existing Torrent PHY driver supports only DisplayPort. This patch series
> prepares Torrent PHY driver so that different multilink configurations can
> be supported. It also updates DT bindings accordingly. This doesn't affect
> ABI as Torrent PHY driver has never been functional, and therefore do not
> exist in any active use case.
> 
> Support for different multilink configurations with register sequences for
> protocols above will be added in a separate patch series.

Applied, thanks

-- 
~Vinod

Re: [PATCH] gpio: aspeed: fix ast2600 bank properties

[Tao Ren]

On Thu, Sep 17, 2020 at 08:42:27AM +0930, Andrew Jeffery wrote:
> 
> 
> On Thu, 17 Sep 2020, at 06:12, rentao.b...@gmail.com wrote:
> > From: Tao Ren 
> > 
> > GPIO_U is mapped to the least significant byte of input/output mask, and
> > the byte in "output" mask should be 0 because GPIO_U is input only. All
> > the other bits need to be 1 because GPIO_V/W/X support both input and
> > output modes.
> > 
> > Similarly, GPIO_Y/Z are mapped to the 2 least significant bytes, and the
> > according bits need to be 1 because GPIO_Y/Z support both input and
> > output modes.
> > 
> > Fixes: ab4a85534c3e ("gpio: aspeed: Add in ast2600 details to Aspeed 
> > driver")
> > Signed-off-by: Tao Ren 
> 
> Thanks Tao,
> 
> Reviewed-by: Andrew Jeffery 

Thanks Andrew for the quick review.

Cheers,

Tao

Re: [PATCH 5/6] scsi: ufs: show ufs part info in error case

[Jaegeuk Kim]

On 09/17, Can Guo wrote:
> On 2020-09-17 00:05, Jaegeuk Kim wrote:
> > On 09/16, Bean Huo wrote:
> > > On Tue, 2020-09-15 at 13:45 -0700, Jaegeuk Kim wrote:
> > > > Cc: Avri Altman 
> > > > Signed-off-by: Jaegeuk Kim 
> > > > ---
> > > >  drivers/scsi/ufs/ufshcd.c | 8 
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> > > > index bdc82cc3824aa..b81c116b976ff 100644
> > > > --- a/drivers/scsi/ufs/ufshcd.c
> > > > +++ b/drivers/scsi/ufs/ufshcd.c
> > > > @@ -500,6 +500,14 @@ static void ufshcd_print_tmrs(struct ufs_hba
> > > > *hba, unsigned long bitmap)
> > > >  static void ufshcd_print_host_state(struct ufs_hba *hba)
> > > >  {
> > > > dev_err(hba->dev, "UFS Host state=%d\n", hba->ufshcd_state);
> > > > +   if (hba->sdev_ufs_device) {
> > > > +   dev_err(hba->dev, " vendor = %.8s\n",
> > > > +   hba->sdev_ufs_device-
> > > > >vendor);
> > > > +   dev_err(hba->dev, " model = %.16s\n",
> > > > +   hba->sdev_ufs_device->model);
> > > > +   dev_err(hba->dev, " rev = %.4s\n",
> > > > +   hba->sdev_ufs_device->rev);
> > > > +   }
> > > 
> > > Hi Jaegeuk
> > > these prints have been added since this change:
> > > 
> > > commit 3f8af6044713 ("scsi: ufs: Add some debug information to
> > > ufshcd_print_host_state()")
> > > 
> > > https://patchwork.kernel.org/patch/11694371/
> > 
> > Cool, thank you for pointing this out. BTW, which branch can I see the
> > -next
> > patches?
> > 
> 
> Hi Jaegeuk,
> 
> This patch comes from a series of changes trying to fix and simplify
> the UFS error handling. You can find the whole series here - they are
> picked up on scsi-queue-5.10
> 
> https://lore.kernel.org/linux-scsi/1596975355-39813-10-git-send-email-c...@codeaurora.org/
> 
> Besides, several more fixes for error handling based on above series are
> 
> https://lore.kernel.org/patchwork/patch/1290405/
> &
> https://lore.kernel.org/linux-scsi/159961731708.5787.8825955850640714260.b4...@oracle.com/
> 
> I've mainline all above changes to Android12-5.4 and Android11-5.4.

I've seen the patches in Android branches. Thank you for the explanation.

> 
> Moreover, there are 2 more fixes on the way for error handling, I
> will push them soon.

BTW, could you please take a look at these patches?

Thanks,

> 
> Thanks,
> 
> Can Guo.
> 
> > > 
> > > Thanks,
> > > Bean

Re: [PATCH 4/6] scsi: ufs: fix LINERESET on hibern8

[Jaegeuk Kim]

Please ignore this patch.
Thanks.

On 09/15, Jaegeuk Kim wrote:
> From: Jaegeuk Kim 
> 
> When testing infinite test to read sysfs entries of UFS, I got a UFS timeout
> with the following kernel message.
> 
> query: dev_cmd_send: seq_no=78082 tag=31, idn=2
> query: ufshcd_wait_for_dev_cmd: dev_cmd request timedout, tag 31
> query: __ufshcd_query_descriptor: opcode 0x01 for idn 2 failed, index 0, err 
> = -11
>  --  hibern8: dme: dme_send: cmd_id=0x17 idn=0
> query: ufshcd_query_descriptor: failed with error -11, retries 3
>  --  hibern8: ufshcd_update_uic_error: LINERESET during hibern8 enter
>  --  hibern8: __ufshcd_uic_hibern8_enter: hibern8 enter failed. ret = -110
> 
> The problem is casued by hibern8 command issued by ufshcd_suspend(), which is
> not aware of query command. If autohibern8 is enabled, we actually don't need
> to issue hibern8 command by suspend.
> 
> Cc: Alim Akhtar 
> Cc: Avri Altman 
> Signed-off-by: Jaegeuk Kim 
> ---
>  drivers/scsi/ufs/ufshcd.c | 20 ++--
>  drivers/scsi/ufs/ufshcd.h |  1 +
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
> index 848e33ec40639..bdc82cc3824aa 100644
> --- a/drivers/scsi/ufs/ufshcd.c
> +++ b/drivers/scsi/ufs/ufshcd.c
> @@ -3079,8 +3079,12 @@ int ufshcd_query_descriptor_retry(struct ufs_hba *hba,
>   int retries;
>  
>   for (retries = QUERY_REQ_RETRIES; retries > 0; retries--) {
> - err = __ufshcd_query_descriptor(hba, opcode, idn, index,
> + err = -EAGAIN;
> + down_read(&hba->query_lock);
> + if (!ufshcd_is_link_hibern8(hba))
> + err = __ufshcd_query_descriptor(hba, opcode, idn, index,
>   selector, desc_buf, buf_len);
> + up_read(&hba->query_lock);
>   if (!err || err == -EINVAL)
>   break;
>   }
> @@ -8263,8 +8267,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
> ufs_pm_op pm_op)
>   enum ufs_pm_level pm_lvl;
>   enum ufs_dev_pwr_mode req_dev_pwr_mode;
>   enum uic_link_state req_link_state;
> + bool need_upwrite = false;
>  
> - hba->pm_op_in_progress = 1;
>   if (!ufshcd_is_shutdown_pm(pm_op)) {
>   pm_lvl = ufshcd_is_runtime_pm(pm_op) ?
>hba->rpm_lvl : hba->spm_lvl;
> @@ -8275,6 +8279,15 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
> ufs_pm_op pm_op)
>   req_link_state = UIC_LINK_OFF_STATE;
>   }
>  
> + if (ufshcd_is_runtime_pm(pm_op) &&
> + req_link_state == UIC_LINK_HIBERN8_STATE &&
> + hba->capabilities & MASK_AUTO_HIBERN8_SUPPORT) {
> + need_upwrite = true;
> + if (!down_write_trylock(&hba->query_lock))
> + return -EBUSY;
> + }
> + hba->pm_op_in_progress = 1;
> +
>   /*
>* If we can't transition into any of the low power modes
>* just gate the clocks.
> @@ -8403,6 +8416,8 @@ static int ufshcd_suspend(struct ufs_hba *hba, enum 
> ufs_pm_op pm_op)
>   }
>  
>   hba->pm_op_in_progress = 0;
> + if (need_upwrite)
> + up_write(&hba->query_lock);
>  
>   if (ret)
>   ufshcd_update_reg_hist(&hba->ufs_stats.suspend_err, (u32)ret);
> @@ -8894,6 +8909,7 @@ int ufshcd_init(struct ufs_hba *hba, void __iomem 
> *mmio_base, unsigned int irq)
>   mutex_init(&hba->dev_cmd.lock);
>  
>   init_rwsem(&hba->clk_scaling_lock);
> + init_rwsem(&hba->query_lock);
>  
>   ufshcd_init_clk_gating(hba);
>  
> diff --git a/drivers/scsi/ufs/ufshcd.h b/drivers/scsi/ufs/ufshcd.h
> index 363589c0bd370..6f8e05eaf9661 100644
> --- a/drivers/scsi/ufs/ufshcd.h
> +++ b/drivers/scsi/ufs/ufshcd.h
> @@ -754,6 +754,7 @@ struct ufs_hba {
>   bool is_urgent_bkops_lvl_checked;
>  
>   struct rw_semaphore clk_scaling_lock;
> + struct rw_semaphore query_lock;
>   unsigned char desc_size[QUERY_DESC_IDN_MAX];
>   atomic_t scsi_block_reqs_cnt;
>  
> -- 
> 2.28.0.618.gf4bc123cb7-goog

[PATCH net] hinic: fix sending pkts from core while self testing

[Luo bin]

Call netif_tx_disable firstly before starting doing self-test to
avoid sending packet from networking core and self-test packet
simultaneously which may cause self-test failure or hw abnormal.

Fixes: 4aa218a4fe77 ("hinic: add self test support")
Signed-off-by: Luo bin 
---
 drivers/net/ethernet/huawei/hinic/hinic_ethtool.c | 4 
 drivers/net/ethernet/huawei/hinic/hinic_tx.c  | 4 ++--
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c 
b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
index 6bb65ade1d77..c340d9acba80 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_ethtool.c
@@ -1654,6 +1654,7 @@ static void hinic_diag_test(struct net_device *netdev,
}
 
netif_carrier_off(netdev);
+   netif_tx_disable(netdev);
 
err = do_lp_test(nic_dev, eth_test->flags, LP_DEFAULT_TIME,
 &test_index);
@@ -1662,9 +1663,12 @@ static void hinic_diag_test(struct net_device *netdev,
data[test_index] = 1;
}
 
+   netif_tx_wake_all_queues(netdev);
+
err = hinic_port_link_state(nic_dev, &link_state);
if (!err && link_state == HINIC_LINK_STATE_UP)
netif_carrier_on(netdev);
+
 }
 
 static int hinic_set_phys_id(struct net_device *netdev,
diff --git a/drivers/net/ethernet/huawei/hinic/hinic_tx.c 
b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
index 2b418b568767..c1f81e9144a1 100644
--- a/drivers/net/ethernet/huawei/hinic/hinic_tx.c
+++ b/drivers/net/ethernet/huawei/hinic/hinic_tx.c
@@ -717,8 +717,8 @@ static int free_tx_poll(struct napi_struct *napi, int 
budget)
netdev_txq = netdev_get_tx_queue(txq->netdev, qp->q_id);
 
__netif_tx_lock(netdev_txq, smp_processor_id());
-
-   netif_wake_subqueue(nic_dev->netdev, qp->q_id);
+   if (!netif_testing(nic_dev->netdev))
+   netif_wake_subqueue(nic_dev->netdev, qp->q_id);
 
__netif_tx_unlock(netdev_txq);
 
-- 
2.17.1

Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication

[Jason Wang]

On 2020/9/16 下午7:47, Kishon Vijay Abraham I wrote:

Hi Jason,

On 16/09/20 8:40 am, Jason Wang wrote:

On 2020/9/15 下午11:47, Kishon Vijay Abraham I wrote:

Hi Jason,

On 15/09/20 1:48 pm, Jason Wang wrote:

Hi Kishon:

On 2020/9/14 下午3:23, Kishon Vijay Abraham I wrote:

Then you need something that is functional equivalent to virtio PCI
which is actually the concept of vDPA (e.g vDPA provides
alternatives if
the queue_sel is hard in the EP implementation).

Okay, I just tried to compare the 'struct vdpa_config_ops' and 'struct
vhost_config_ops' ( introduced in [RFC PATCH 03/22] vhost: Add ops for
the VHOST driver to configure VHOST device).

struct vdpa_config_ops {
  /* Virtqueue ops */
  int (*set_vq_address)(struct vdpa_device *vdev,
    u16 idx, u64 desc_area, u64 driver_area,
    u64 device_area);
  void (*set_vq_num)(struct vdpa_device *vdev, u16 idx, u32 num);
  void (*kick_vq)(struct vdpa_device *vdev, u16 idx);
  void (*set_vq_cb)(struct vdpa_device *vdev, u16 idx,
    struct vdpa_callback *cb);
  void (*set_vq_ready)(struct vdpa_device *vdev, u16 idx, bool
ready);
  bool (*get_vq_ready)(struct vdpa_device *vdev, u16 idx);
  int (*set_vq_state)(struct vdpa_device *vdev, u16 idx,
  const struct vdpa_vq_state *state);
  int (*get_vq_state)(struct vdpa_device *vdev, u16 idx,
  struct vdpa_vq_state *state);
  struct vdpa_notification_area
  (*get_vq_notification)(struct vdpa_device *vdev, u16 idx);
  /* vq irq is not expected to be changed once DRIVER_OK is set */
  int (*get_vq_irq)(struct vdpa_device *vdv, u16 idx);

  /* Device ops */
  u32 (*get_vq_align)(struct vdpa_device *vdev);
  u64 (*get_features)(struct vdpa_device *vdev);
  int (*set_features)(struct vdpa_device *vdev, u64 features);
  void (*set_config_cb)(struct vdpa_device *vdev,
    struct vdpa_callback *cb);
  u16 (*get_vq_num_max)(struct vdpa_device *vdev);
  u32 (*get_device_id)(struct vdpa_device *vdev);
  u32 (*get_vendor_id)(struct vdpa_device *vdev);
  u8 (*get_status)(struct vdpa_device *vdev);
  void (*set_status)(struct vdpa_device *vdev, u8 status);
  void (*get_config)(struct vdpa_device *vdev, unsigned int offset,
     void *buf, unsigned int len);
  void (*set_config)(struct vdpa_device *vdev, unsigned int offset,
     const void *buf, unsigned int len);
  u32 (*get_generation)(struct vdpa_device *vdev);

  /* DMA ops */
  int (*set_map)(struct vdpa_device *vdev, struct vhost_iotlb
*iotlb);
  int (*dma_map)(struct vdpa_device *vdev, u64 iova, u64 size,
     u64 pa, u32 perm);
  int (*dma_unmap)(struct vdpa_device *vdev, u64 iova, u64 size);

  /* Free device resources */
  void (*free)(struct vdpa_device *vdev);
};

+struct vhost_config_ops {
+    int (*create_vqs)(struct vhost_dev *vdev, unsigned int nvqs,
+  unsigned int num_bufs, struct vhost_virtqueue *vqs[],
+  vhost_vq_callback_t *callbacks[],
+  const char * const names[]);
+    void (*del_vqs)(struct vhost_dev *vdev);
+    int (*write)(struct vhost_dev *vdev, u64 vhost_dst, void *src,
int len);
+    int (*read)(struct vhost_dev *vdev, void *dst, u64 vhost_src, int
len);
+    int (*set_features)(struct vhost_dev *vdev, u64 device_features);
+    int (*set_status)(struct vhost_dev *vdev, u8 status);
+    u8 (*get_status)(struct vhost_dev *vdev);
+};
+
struct virtio_config_ops
I think there's some overlap here and some of the ops tries to do the
same thing.

I think it differs in (*set_vq_address)() and (*create_vqs)().
[create_vqs() introduced in struct vhost_config_ops provides
complimentary functionality to (*find_vqs)() in struct
virtio_config_ops. It seemingly encapsulates the functionality of
(*set_vq_address)(), (*set_vq_num)(), (*set_vq_cb)(),..].

Back to the difference between (*set_vq_address)() and (*create_vqs)(),
set_vq_address() directly provides the virtqueue address to the vdpa
device but create_vqs() only provides the parameters of the virtqueue
(like the number of virtqueues, number of buffers) but does not
directly
provide the address. IMO the backend client drivers (like net or vhost)
shouldn't/cannot by itself know how to access the vring created on
virtio front-end. The vdpa device/vhost device should have logic for
that. That will help the client drivers to work with different types of
vdpa device/vhost device and can access the vring created by virtio
irrespective of whether the vring can be accessed via mmio or kernel
space or user space.

I think vdpa always works with client drivers in userspace and
providing
userspace address for vring.

Sorry for being unclear. What I meant is not replacing vDPA with the
vhost(bus) you proposed but the possibility of replacing virtio-pci-epf
with vDPA in:

Okay, so the virtio back-end still use vhost and front end 

Re: [PATCH] iomap: Fix the write_count in iomap_add_to_ioend().

[Darrick J. Wong]

On Thu, Sep 17, 2020 at 03:48:04PM +0100, Christoph Hellwig wrote:
> On Thu, Sep 17, 2020 at 06:42:19AM -0400, Brian Foster wrote:
> > That wouldn't address the latency concern Dave brought up. That said, I
> > have no issue with this as a targeted solution for the softlockup issue.
> > iomap_finish_ioend[s]() is common code for both the workqueue and
> > ->bi_end_io() contexts so that would require either some kind of context
> > detection (and my understanding is in_atomic() is unreliable/frowned
> > upon) or a new "atomic" parameter through iomap_finish_ioend[s]() to
> > indicate whether it's safe to reschedule. Preference?
> 
> True, it would not help with latency.  But then again the latency
> should be controlled by the writeback code not doing giant writebacks
> to start with, shouldn't it?
> 
> Any XFS/iomap specific limit also would not help with the block layer
> merging bios.

/me hasn't totally been following this thread, but iomap will also
aggregate the ioend completions; do we need to cap that to keep
latencies down?  I was assuming that amortization was always favorable,
but maybe not?

--D

RE: [PATCH v3] drm/bridge: add it6505 driver

[allen.chen]

It has been about two weeks since I posted v3 and haven't heard anything.
Consider this a gentle ping.

If there is something need to fix. I will fix and upstream again.

Thanks.

-Original Message-
From: Allen Chen (陳柏宇) 
Sent: Friday, September 04, 2020 10:10 AM
Cc: Allen Chen (陳柏宇); Kenneth Hung (洪家倫); Jau-Chih Tseng (曾昭智); Hermes Wu 
(吳佳宏); Pi-Hsun Shih; Jitao Shi; Yilun Lin; Hermes Wu (吳佳宏); kernel test robot; 
Andrzej Hajda; Neil Armstrong; Laurent Pinchart; Jonas Karlman; Jernej Skrabec; 
David Airlie; Daniel Vetter; Matthias Brugger; open list; open list:DRM 
DRIVERS; moderated list:ARM/Mediatek SoC support; moderated list:ARM/Mediatek 
SoC support
Subject: [PATCH v3] drm/bridge: add it6505 driver

This adds support for the iTE IT6505.
This device can convert DPI signal to DP output.

From: Allen Chen 
Signed-off-by: Jitao Shi 
Signed-off-by: Pi-Hsun Shih 
Signed-off-by: Yilun Lin 
Signed-off-by: Hermes Wu 
Signed-off-by: Allen Chen 
Reported-by: kernel test robot 
---
 drivers/gpu/drm/bridge/Kconfig  |7 +
 drivers/gpu/drm/bridge/Makefile |1 +
 drivers/gpu/drm/bridge/ite-it6505.c | 3338 +++
 3 files changed, 3346 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/ite-it6505.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3e11af4e9f63e..f21dce3fabeb9 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -61,6 +61,13 @@ config DRM_LONTIUM_LT9611
  HDMI signals
  Please say Y if you have such hardware.
 
+config DRM_ITE_IT6505
+   tristate "ITE IT6505 DisplayPort bridge"
+   depends on OF
+   select DRM_KMS_HELPER
+   help
+ ITE IT6505 DisplayPort bridge chip driver.
+
 config DRM_LVDS_CODEC
tristate "Transparent LVDS encoders and decoders support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index c589a6a7cbe1d..8a118fd901ad7 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,6 +3,7 @@ obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_CHRONTEL_CH7033) += chrontel-ch7033.o
 obj-$(CONFIG_DRM_DISPLAY_CONNECTOR) += display-connector.o
 obj-$(CONFIG_DRM_LONTIUM_LT9611) += lontium-lt9611.o
+obj-$(CONFIG_DRM_ITE_IT6505) += ite-it6505.o
 obj-$(CONFIG_DRM_LVDS_CODEC) += lvds-codec.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
diff --git a/drivers/gpu/drm/bridge/ite-it6505.c 
b/drivers/gpu/drm/bridge/ite-it6505.c
new file mode 100644
index 0..0ed19673431ee
--- /dev/null
+++ b/drivers/gpu/drm/bridge/ite-it6505.c
@@ -0,0 +1,3338 @@
+// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+/*
+ * Copyright (c) 2020, The Linux Foundation. All rights reserved.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define REG_IC_VER 0x04
+
+#define REG_RESET_CTRL 0x05
+#define VIDEO_RESET BIT(0)
+#define AUDIO_RESET BIT(1)
+#define ALL_LOGIC_RESET BIT(2)
+#define AUX_RESET BIT(3)
+#define HDCP_RESET BIT(4)
+
+#define INT_STATUS_01 0x06
+#define INT_MASK_01 0x09
+#define INT_HPD_CHANGE BIT(0)
+#define INT_RECEIVE_HPD_IRQ BIT(1)
+#define INT_SCDT_CHANGE BIT(2)
+#define INT_HDCP_FAIL BIT(3)
+#define INT_HDCP_DONE BIT(4)
+
+#define INT_STATUS_02 0x07
+#define INT_MASK_02 0x0A
+#define INT_AUX_CMD_FAIL BIT(0)
+#define INT_HDCP_KSV_CHECK BIT(1)
+#define INT_AUDIO_FIFO_ERROR BIT(2)
+
+#define INT_STATUS_03 0x08
+#define INT_MASK_03 0x0B
+#define INT_LINK_TRAIN_FAIL BIT(4)
+#define INT_VID_FIFO_ERROR BIT(5)
+#define INT_IO_LATCH_FIFO_OVERFLOW BIT(7)
+
+#define REG_SYSTEM_STS 0x0D
+#define INT_STS BIT(0)
+#define HPD_STS BIT(1)
+#define VIDEO_STB BIT(2)
+
+#define REG_LINK_TRAIN_STS 0x0E
+#define LINK_STATE_CR BIT(2)
+#define LINK_STATE_EQ BIT(3)
+#define LINK_STATE_NORP BIT(4)
+
+#define REG_BANK_SEL 0x0F
+#define REG_CLK_CTRL0 0x10
+#define M_PCLK_DELAY 0x03
+
+#define REG_AUX_OPT 0x11
+#define AUX_AUTO_RST BIT(0)
+#define AUX_FIX_FREQ BIT(3)
+
+#define REG_DATA_CTRL0 0x12
+#define VIDEO_LATCH_EDGE BIT(4)
+#define ENABLE_PCLK_COUNTER BIT(7)
+
+#define REG_PCLK_COUNTER_VALUE 0x13
+
+#define REG_501_FIFO_CTRL 0x15
+#define RST_501_FIFO BIT(1)
+
+#define REG_TRAIN_CTRL0 0x16
+#define FORCE_LBR BIT(0)
+#define LANE_COUNT_MASK 0x06
+#define LANE_SWAP BIT(3)
+#define SPREAD_AMP_5 BIT(4)
+#define FORCE_CR_DONE BIT(5)
+#define FORCE_EQ_DONE BIT(6)
+
+#define REG_TRAIN_CTRL1 0x17
+#define AUTO_TRAIN BIT(0)
+#define MANUAL_TRAIN BIT(1)
+#define FORCE_RETRAIN BIT(2)
+
+#define REG_AUX_CTRL 0x23
+#define CLR_EDID_FIFO BIT(0)
+#define AUX_USER_MODE BIT(1)
+#define AUX_NO_SEGMENT_WR BIT(6)
+#define A

Re: [PATCH v12 3/9] x86: kdump: use macro CRASH_ADDR_LOW_MAX in functions reserve_crashkernel[_low]()

[chenzhou]

Hi Dave,


On 2020/9/18 11:01, Dave Young wrote:
> On 09/07/20 at 09:47pm, Chen Zhou wrote:
>> To make the functions reserve_crashkernel[_low]() as generic,
>> replace some hard-coded numbers with macro CRASH_ADDR_LOW_MAX.
>>
>> Signed-off-by: Chen Zhou 
>> ---
>>  arch/x86/kernel/setup.c | 11 ++-
>>  1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
>> index d7fd90c52dae..71a6a6e7ca5b 100644
>> --- a/arch/x86/kernel/setup.c
>> +++ b/arch/x86/kernel/setup.c
>> @@ -430,7 +430,7 @@ static int __init reserve_crashkernel_low(void)
>>  unsigned long total_low_mem;
>>  int ret;
>>  
>> -total_low_mem = memblock_mem_size(1UL << (32 - PAGE_SHIFT));
>> +total_low_mem = memblock_mem_size(CRASH_ADDR_LOW_MAX >> PAGE_SHIFT);
> total_low_mem != CRASH_ADDR_LOW_MAX
I just replace the magic number with macro, no other change.
Besides, function memblock_mem_size(limit_pfn) will compute the memory size
according to the actual system ram.

Thanks,
Chen Zhou
>
>>  
>>  /* crashkernel=Y,low */
>>  ret = parse_crashkernel_low(boot_command_line, total_low_mem, 
>> &low_size, &base);
> The param total_low_mem is for dynamically change crash_size according
> to system ram size.
>
> Is above change a must for your arm64 patches?
See above.
>
>> @@ -451,7 +451,7 @@ static int __init reserve_crashkernel_low(void)
>>  return 0;
>>  }
>>  
>> -low_base = memblock_find_in_range(CRASH_ALIGN, 1ULL << 32, low_size, 
>> CRASH_ALIGN);
>> +low_base = memblock_find_in_range(CRASH_ALIGN, CRASH_ADDR_LOW_MAX, 
>> low_size, CRASH_ALIGN);
>>  if (!low_base) {
>>  pr_err("Cannot reserve %ldMB crashkernel low memory, please try 
>> smaller size.\n",
>> (unsigned long)(low_size >> 20));
>> @@ -504,8 +504,9 @@ static void __init reserve_crashkernel(void)
>>  if (!crash_base) {
>>  /*
>>   * Set CRASH_ADDR_LOW_MAX upper bound for crash memory,
>> - * crashkernel=x,high reserves memory over 4G, also allocates
>> - * 256M extra low memory for DMA buffers and swiotlb.
>> + * crashkernel=x,high reserves memory over CRASH_ADDR_LOW_MAX,
>> + * also allocates 256M extra low memory for DMA buffers
>> + * and swiotlb.
>>   * But the extra memory is not required for all machines.
>>   * So try low memory first and fall back to high memory
>>   * unless "crashkernel=size[KMG],high" is specified.
>> @@ -539,7 +540,7 @@ static void __init reserve_crashkernel(void)
>>  return;
>>  }
>>  
>> -if (crash_base >= (1ULL << 32) && reserve_crashkernel_low()) {
>> +if (crash_base >= CRASH_ADDR_LOW_MAX && reserve_crashkernel_low()) {
>>  memblock_free(crash_base, crash_size);
>>  return;
>>  }
>> -- 
>> 2.20.1
>>
> .
>

Re: linux-next: Tree for Sep 17 (netdevice.h: net_has_fallback_tunnels when SYSCTL is not set)

[महेश बंडेवार]

On Thu, Sep 17, 2020 at 1:33 PM Randy Dunlap  wrote:
>
> On 9/17/20 3:23 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200916:
> >
>
> I am seeing build errors when CONFIG_SYSCTL is not set:
>
> ld: net/ipv4/ip_tunnel.o: in function `ip_tunnel_init_net':
> ip_tunnel.c:(.text+0x2ea0): undefined reference to 
> `sysctl_fb_tunnels_only_for_init_net'
> ld: net/ipv6/ip6_vti.o: in function `vti6_init_net':
> ip6_vti.c:(.text+0x1b56): undefined reference to 
> `sysctl_fb_tunnels_only_for_init_net'
> ld: net/ipv6/sit.o: in function `sit_init_net':
> sit.c:(.text+0x4568): undefined reference to 
> `sysctl_fb_tunnels_only_for_init_net'
> ld: net/ipv6/ip6_tunnel.o: in function `ip6_tnl_init_net':
> ip6_tunnel.c:(.text+0x27d6): undefined reference to 
> `sysctl_fb_tunnels_only_for_init_net'
> ld: net/ipv6/ip6_gre.o: in function `ip6gre_init_net':
> ip6_gre.c:(.text+0x3a5e): undefined reference to 
> `sysctl_fb_tunnels_only_for_init_net'
>
> due to 316cdaa1158af:
>
> commit 316cdaa1158af17250397054f92bb339fbd8e282
> Author: Mahesh Bandewar 
> Date:   Wed Aug 26 09:05:35 2020 -0700
>
> net: add option to not create fall-back tunnels in root-ns as well
>
>
> This was first reported to netdev@ on Sept. 02 but Mahesh was not cc-ed
> on that report.
>
Thanks Randy for the report.
Probably we shouldn't have removed the !ENBALED(CONFIG_SYSCTL) check.
Let me cook a fix and send it.
>
> --
> ~Randy
> Reported-by: Randy Dunlap 

[PATCH -next] drm/amd/display: remove unused variable in amdgpu_dm.c

[Yang Yingliang]

Fix the compile warning:
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:892:26: warning: 
variable ‘stream’ set but not used [-Wunused-but-set-variable]
  struct dc_stream_state *stream;
  ^~

Reported-by: Hulk Robot 
Signed-off-by: Yang Yingliang 
---
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c 
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index bb1bc7f5d149..7d9e8c311879 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -889,7 +889,6 @@ static void 
amdgpu_check_debugfs_connector_property_change(struct amdgpu_device
struct drm_connector_state *conn_state;
struct dm_crtc_state *acrtc_state;
struct drm_crtc_state *crtc_state;
-   struct dc_stream_state *stream;
struct drm_device *dev = adev_to_drm(adev);
 
list_for_each_entry(connector, &dev->mode_config.connector_list, head) {
@@ -906,8 +905,6 @@ static void 
amdgpu_check_debugfs_connector_property_change(struct amdgpu_device
if (!(acrtc_state && acrtc_state->stream))
continue;
 
-   stream = acrtc_state->stream;
-
if (amdgpu_dm_connector->dsc_settings.dsc_force_enable ||
amdgpu_dm_connector->dsc_settings.dsc_num_slices_v ||
amdgpu_dm_connector->dsc_settings.dsc_num_slices_h ||
-- 
2.25.1

Re: [PATCH 1/7] usb: mtu3: convert to devm_platform_ioremap_resource_byname

[Chunfeng Yun]

Hi Felip,


On Mon, 2020-09-07 at 10:42 +0300, Felipe Balbi wrote:
> Hi,
> 
> Chunfeng Yun  writes:
> > Use devm_platform_ioremap_resource_byname() to simplify code
> >
> > Signed-off-by: Chunfeng Yun 
> 
> why is it so that your patches always come base64 encoded? They look
> fine on the email client, but when I try to pipe the message to git am
> it always gives me a lot of trouble and I have to manually decode the
> body of your messages and recombine with the patch.
> 
> Can you try to send your patches as actual plain text without encoding
> the body with base64?
Missed the email.

Sorry for inconvenience!
Is only the commit message base64 encoded, or includes the codes?

> 

Re: [PATCH 1/2] locktorture: doesn't check nreaders_stress when no readlock support

[Paul E. McKenney]

On Fri, Sep 18, 2020 at 09:13:14AM +0800, Hou Tao wrote:
> Hi Paul,
> 
> On 2020/9/18 0:58, Paul E. McKenney wrote:
> > On Thu, Sep 17, 2020 at 09:59:09PM +0800, Hou Tao wrote:
> >> To ensure there is always at least one locking thread.
> >>
> >> Signed-off-by: Hou Tao 
> >> ---
> >>  kernel/locking/locktorture.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/kernel/locking/locktorture.c b/kernel/locking/locktorture.c
> >> index 9cfa5e89cff7f..bebdf98e6cd78 100644
> >> --- a/kernel/locking/locktorture.c
> >> +++ b/kernel/locking/locktorture.c
> >> @@ -868,7 +868,8 @@ static int __init lock_torture_init(void)
> >>goto unwind;
> >>}
> >>  
> >> -  if (nwriters_stress == 0 && nreaders_stress == 0) {
> >> +  if (nwriters_stress == 0 &&
> >> +  (!cxt.cur_ops->readlock || nreaders_stress == 0)) {
> > 
> > You lost me on this one.  How does it help to allow tests with zero
> > writers on exclusive locks?  Or am I missing something subtle here?
> > 
> The purpose is to prohibit test with only readers on exclusive locks, not 
> allow it.
> 
> So if the module parameters are "torture_type=mutex_lock nwriters_stress=0 
> nreaders_stress=3",
> locktorture can fail early instead of continuing but doing nothing useful.

Very good!

Now please make that clear in the commit log.  (Your English looks to
me to be more than equal to that challenge.)

In this commit log, please first state what is wrong.  Then what the
change is and how it improves things.

Thanx, Paul

> Regards,
> Tao
> 
> > Thanx, Paul
> > 
> >>pr_alert("lock-torture: must run at least one locking 
> >> thread\n");
> >>firsterr = -EINVAL;
> >>goto unwind;
> >> -- 
> >> 2.25.0.4.g0ad7144999
> >>
> > .
> > 

Re: [PATCH] selftests/harness: Flush stdout before forking

[Michael Ellerman]

Shuah Khan  writes:
> On 9/16/20 10:53 PM, Max Filippov wrote:
>> On Wed, Sep 16, 2020 at 9:16 PM Michael Ellerman  wrote:
>>>
>>> The test harness forks() a child to run each test. Both the parent and
>>> the child print to stdout using libc functions. That can lead to
>>> duplicated (or more) output if the libc buffers are not flushed before
>>> forking.
>>>
>>> It's generally not seen when running programs directly, because stdout
>>> will usually be line buffered when it's pointing to a terminal.
>>>
>>> This was noticed when running the seccomp_bpf test, eg:
>>>
>>>$ ./seccomp_bpf | tee test.log
>>>$ grep -c "TAP version 13" test.log
>>>2
>>>
>>> But we only expect the TAP header to appear once.
>>>
>>> It can be exacerbated using stdbuf to increase the buffer size:
>>>
>>>$ stdbuf -o 1MB ./seccomp_bpf > test.log
>>>$ grep -c "TAP version 13" test.log
>>>13
>>>
>>> The fix is simple, we just flush stdout & stderr before fork. Usually
>>> stderr is unbuffered, but that can be changed, so flush it as well
>>> just to be safe.
>>>
>>> Signed-off-by: Michael Ellerman 
>>> ---
>>>   tools/testing/selftests/kselftest_harness.h | 5 +
>>>   1 file changed, 5 insertions(+)
>> 
>> Tested-by: Max Filippov 
>
> Thank you both. Applying to linux-kselftest fixes for 5.9-rc7

It can wait for v5.10 IMHO, but up to you.

cheers

[PATCH v3] EDAC/mc_sysfs: Add missing newlines when printing {max,dimm}_location

[Xiongfeng Wang]

Reading those sysfs entries gives:

  [root@localhost /]# cat /sys/devices/system/edac/mc/mc0/max_location
  memory 3 [root@localhost /]# cat 
/sys/devices/system/edac/mc/mc0/dimm0/dimm_location
  memory 0 [root@localhost /]#

Add newlines after the value it prints for better readability.

Signed-off-by: Xiongfeng Wang 
Signed-off-by: Borislav Petkov 
Suggested-by: Joe Perches 
---
 drivers/edac/edac_mc_sysfs.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/edac/edac_mc_sysfs.c b/drivers/edac/edac_mc_sysfs.c
index 4e6aca5..2f9f1e7 100644
--- a/drivers/edac/edac_mc_sysfs.c
+++ b/drivers/edac/edac_mc_sysfs.c
@@ -474,8 +474,12 @@ static ssize_t dimmdev_location_show(struct device *dev,
 struct device_attribute *mattr, char *data)
 {
struct dimm_info *dimm = to_dimm(dev);
+   ssize_t count;
 
-   return edac_dimm_info_location(dimm, data, PAGE_SIZE);
+   count = edac_dimm_info_location(dimm, data, PAGE_SIZE);
+   count += scnprintf(data + count, PAGE_SIZE - count, "\n");
+
+   return count;
 }
 
 static ssize_t dimmdev_label_show(struct device *dev,
@@ -813,15 +817,23 @@ static ssize_t mci_max_location_show(struct device *dev,
 char *data)
 {
struct mem_ctl_info *mci = to_mci(dev);
-   int i;
+   int len = PAGE_SIZE;
char *p = data;
+   int i, n;
 
for (i = 0; i < mci->n_layers; i++) {
-   p += sprintf(p, "%s %d ",
-edac_layer_name[mci->layers[i].type],
-mci->layers[i].size - 1);
+   n = scnprintf(p, len, "%s %d ",
+ edac_layer_name[mci->layers[i].type],
+ mci->layers[i].size - 1);
+   len -= n;
+   if (len <= 0)
+   goto out;
+
+   p += n;
}
 
+   p += scnprintf(p, len, "\n");
+out:
return p - data;
 }
 
-- 
1.7.12.4

[PATCH v2] arm64: Enable PCI write-combine resources under sysfs

[Clint Sbisa]

This change exposes write-combine mappings under sysfs for
prefetchable PCI resources on arm64.

Originally, the usage of "write combine" here was driven by the x86
definition of write combine. This definition is specific to x86 and
does not generalize to other architectures. However, the usage of WC
has mutated to "write combine" semantics, which is implemented
differently on each arch.

Generally, prefetchable BARs are accepted to allow speculative
accesses, write combining, and re-ordering-- from the PCI perspective,
this means there are no read side effects. (This contradicts the PCI
spec which allows prefetchable BARs to have read side effects, but
this definition is ill-advised as it is impossible to meet.) On x86,
prefetchable BARs are mapped as WC as originally defined (with some
conditionals on arch features). On arm64, WC is taken to mean normal
non-cacheable memory.

In practice, write combine semantics are used to minimize write
operations. A common usage of this is minimizing PCI TLPs which can
significantly improve performance with PCI devices. In order to
provide the same benefits to userspace, we need to allow userspace to
map prefetchable BARs with write combine semantics. The resourceX_wc
mapping is used today by userspace programs and libraries.

While this model is flawed as "write combine" is very ill-defined, it
is already used by multiple non-x86 archs to expose write combine
semantics to user space. We enable this on arm64 to give userspace on
arm64 an equivalent mechanism for utilizing write combining with PCI
devices.

Cc: Benjamin Herrenschmidt 
Cc: Bjorn Helgaas 
Cc: Catalin Marinas 
Cc: Jason Gunthorpe 
Cc: Lorenzo Pieralisi 
Cc: Will Deacon 
Signed-off-by: Clint Sbisa 
---
Changes in v2:
  - Rewrote the commit message.

 arch/arm64/include/asm/pci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
index 70b323cf8300..b33ca260e3c9 100644
--- a/arch/arm64/include/asm/pci.h
+++ b/arch/arm64/include/asm/pci.h
@@ -17,6 +17,7 @@
 #define pcibios_assign_all_busses() \
(pci_has_flag(PCI_REASSIGN_ALL_BUS))
 
+#define arch_can_pci_mmap_wc() 1
 #define ARCH_GENERIC_PCI_MMAP_RESOURCE 1
 
 extern int isa_dma_bridge_buggy;
-- 
2.23.3

Re: [PATCH] nvme: fix NULL pointer dereference

[Tong Zhang]

Please correct me if I am wrong.
After a bit more digging I found out that it is indeed command_id got
corrupted is causing this problem. Although the tag and command_id
range is checked like you said, the elements in rqs cannot be
guaranteed to be not NULL. thus although the range check is passed,
blk_mq_tag_to_rq() can still return NULL. It is clear that the current
sanitization is not enough and there's more implication about this --
when all rqs got populated, a corrupted command_id may silently
corrupt other data not belonging to the current command.

- Tong

On Thu, Sep 17, 2020 at 8:44 PM Tong Zhang  wrote:
>
> Hmm..Yeah.. I see your point.
> I was naivly thinking the command_id was the culprit.
>
> On Thu, Sep 17, 2020 at 1:14 PM Keith Busch  wrote:
> >
> > On Thu, Sep 17, 2020 at 12:56:59PM -0400, Tong Zhang wrote:
> > > The command_id in CQE is writable by NVMe controller, driver should
> > > check its sanity before using it.
> >
> > We already do that.

Re: [PATCH RFC 0/3] scsi: mpt: Refactor and port to dma_* interface

[Martin K. Petersen]

Alex,

>> Have you tested your changes?
>
> No, as I'm afraid I don't have the hardware.

QEMU supports it, I propose you try testing with that.

I hesitate merging big changes to abandoned drivers unless they've been
tested. It's too easy to miss things during review...

-- 
Martin K. Petersen  Oracle Linux Engineering

[PATCH] Only allow to set crash_kexec_post_notifiers on boot time

[Dave Young]

crash_kexec_post_notifiers enables running various panic notifier
before kdump kernel booting. This increases risks of kdump failure.
It is well documented in kernel-parameters.txt. We do not suggest
people to enable it together with kdump unless he/she is really sure.
This is also not suggested to be enabled by default when users are
not aware in distributions.

But unfortunately it is enabled by default in systemd, see below
discussions in a systemd report, we can not convince systemd to change
it:
https://github.com/systemd/systemd/issues/16661

Actually we have got reports about kdump kernel hangs in both s390x
and powerpcle cases caused by the systemd change,  also some x86 cases
could also be caused by the same (although that is in Hyper-V code
instead of systemd, that need to be addressed separately).

Thus to avoid the auto enablement here just disable the param writable
permission in sysfs.

Signed-off-by: Dave Young 
---
 kernel/panic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/panic.c b/kernel/panic.c
index aef8872ba843..bea44fc4eb3b 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -695,7 +695,7 @@ core_param(panic, panic_timeout, int, 0644);
 core_param(panic_print, panic_print, ulong, 0644);
 core_param(pause_on_oops, pause_on_oops, int, 0644);
 core_param(panic_on_warn, panic_on_warn, int, 0644);
-core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0644);
+core_param(crash_kexec_post_notifiers, crash_kexec_post_notifiers, bool, 0444);
 
 static int __init oops_setup(char *s)
 {
-- 
2.26.2