* Re: [PATCH v2 1/3] scsi: core: allow auto suspend override by low-level driver
From: Bart Van Assche @ 2019-09-12 13:43 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, martin.petersen, avri.altman,
alim.akhtar, pedrom.sousa, sthumma, jejb
Cc: marc.w.gonzalez, andy.teng, chun-hung.wu, kuohong.wang, evgreen,
subhashj, linux-mediatek, peter.wang, vivek.gautam, matthias.bgg,
linux-arm-kernel, beanhuo
In-Reply-To: <1568270135-32442-2-git-send-email-stanley.chu@mediatek.com>
On 9/12/19 7:35 AM, Stanley Chu wrote:
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index 64c96c7828ee..461aafadd208 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -1300,7 +1300,8 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
> device_enable_async_suspend(&sdev->sdev_gendev);
> scsi_autopm_get_target(starget);
> pm_runtime_set_active(&sdev->sdev_gendev);
> - pm_runtime_forbid(&sdev->sdev_gendev);
> + if (sdev->rpm_autosuspend_delay < 0)
> + pm_runtime_forbid(&sdev->sdev_gendev);
> pm_runtime_enable(&sdev->sdev_gendev);
> scsi_autopm_put_target(starget);
So we have a single new struct member, rpm_autosuspend_delay, that
controls two different behaviors: (a) whether or not runtime suspend is
enabled at device creation time and (b) the power management autosuspend
delay. I don't like this. Should two separate variables be introduced
instead of using a single variable to control both behaviors?
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index 202f4d6a4342..133b282fae5a 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -199,7 +199,7 @@ struct scsi_device {
> unsigned broken_fua:1; /* Don't set FUA bit */
> unsigned lun_in_cdb:1; /* Store LUN bits in CDB[1] */
> unsigned unmap_limit_for_ws:1; /* Use the UNMAP limit for WRITE SAME */
> -
> + int rpm_autosuspend_delay;
> atomic_t disk_events_disable_depth; /* disable depth for disk events */
>
> DECLARE_BITMAP(supported_events, SDEV_EVT_MAXBITS); /* supported events */
>
Since the default value for the autosuspend delay is the same for all
SCSI devices attached to a SCSI host is the same, please add a variable
with the same name in the SCSI host template and use that value as the
default value for SCSI devices. If the rpm_autosuspend_delay variable
only occurs in struct scsi_device then LLD authors are forced to
introduce a slave_configure function. Introducing such a function can be
avoided if the default autosuspend delay can be specified in the host
template.
Bart.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] fixup null q->dev checking in both block and scsi layer
From: Jens Axboe @ 2019-09-12 13:12 UTC (permalink / raw)
To: Stanley Chu, linux-scsi, linux-block, martin.petersen, jejb,
matthias.bgg
Cc: andy.teng, chun-hung.wu, kuohong.wang, linux-mediatek, peter.wang,
linux-arm-kernel
In-Reply-To: <1568277328-4597-1-git-send-email-stanley.chu@mediatek.com>
On 9/12/19 2:35 AM, Stanley Chu wrote:
> Some devices may skip blk_pm_runtime_init() and have null pointer in
> its request_queue->dev. For example, SCSI devices of UFS Well-Known
> LUNs.
>
> Currently the null pointer is checked by the user of
> blk_set_runtime_active(), i.e., scsi_dev_type_resume(). It is better
> to check it by blk_set_runtime_active() itself instead of by its
> users.
Applied, thanks.
--
Jens Axboe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] arm64: fix function types in COND_SYSCALL
From: Will Deacon @ 2019-09-12 13:11 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, Catalin Marinas, Kees Cook, Sami Tolvanen,
linux-kernel
In-Reply-To: <20190911151545.GD3360@blommer>
On Wed, Sep 11, 2019 at 04:15:46PM +0100, Mark Rutland wrote:
> On Tue, Sep 10, 2019 at 03:40:44PM -0700, Sami Tolvanen wrote:
> > Define a weak function in COND_SYSCALL instead of a weak alias to
> > sys_ni_syscall, which has an incompatible type. This fixes indirect
> > call mismatches with Control-Flow Integrity (CFI) checking.
> >
> > Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
>
> This looks correct to me, builds fine, and I asume has been tested, so FWIW:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
>
> In looking at this, I came to the conclusion that we can drop the ifdeffery
> around our SYSCALL_DEFINE0(), COND_SYSCALL(), and SYS_NI(), which I evidently
> cargo-culted from x86 (where the ifdeffery is actually necessary).
Curious: why is it required on x86?
> I can send a follow up for that.
Yes, please.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for ls1088a
From: Andrew Murray @ 2019-09-12 13:01 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <AM5PR04MB329926C6F424C4BE1CE9B787F5B90@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Tue, Sep 03, 2019 at 02:01:32AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年9月2日 21:06
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> > Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> > arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> > <zhiqiang.hou@nxp.com>
> > Subject: Re: [PATCH v3 10/11] arm64: dts: layerscape: Add PCIe EP node for
> > ls1088a
> >
> > On Mon, Sep 02, 2019 at 11:17:15AM +0800, Xiaowei Bao wrote:
> > > Add PCIe EP node for ls1088a to support EP mode.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - Remove the pf-offset proparty.
> > > v3:
> > > - No change.
> > >
> > > arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 31
> > ++++++++++++++++++++++++++
> > > 1 file changed, 31 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > index c676d07..da246ab 100644
> > > --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> > > @@ -483,6 +483,17 @@
> > > status = "disabled";
> > > };
> > >
> > > + pcie_ep@3400000 {
> > > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> >
> > Here you specify a fallback "fsl,ls-pcie-ep" that is removed by this series.
> >
> > Besides that, this looks OK.
>
> As explained, the "fsl,ls-pcie-ep" is needed, due to the u-boot will fixup the status
> property base on this compatible, I think we reserve this compatible is helpfully,
> if delate this compatible, I have to modify the code of bootloader.
I assume you mean that u-boot fixes up "fsl,ls-pcie-ep" *only* for ls1046a
devices?
Thanks,
Andrew Murray
>
> Thanks
> XIaowei
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > + reg = <0x00 0x03400000 0x0 0x00100000
> > > + 0x20 0x00000000 0x8 0x00000000>;
> > > + reg-names = "regs", "addr_space";
> > > + num-ib-windows = <24>;
> > > + num-ob-windows = <128>;
> > > + max-functions = /bits/ 8 <2>;
> > > + status = "disabled";
> > > + };
> > > +
> > > pcie@3500000 {
> > > compatible = "fsl,ls1088a-pcie";
> > > reg = <0x00 0x03500000 0x0 0x00100000 /* controller
> > registers */
> > > @@ -508,6 +519,16 @@
> > > status = "disabled";
> > > };
> > >
> > > + pcie_ep@3500000 {
> > > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > > + reg = <0x00 0x03500000 0x0 0x00100000
> > > + 0x28 0x00000000 0x8 0x00000000>;
> > > + reg-names = "regs", "addr_space";
> > > + num-ib-windows = <6>;
> > > + num-ob-windows = <8>;
> > > + status = "disabled";
> > > + };
> > > +
> > > pcie@3600000 {
> > > compatible = "fsl,ls1088a-pcie";
> > > reg = <0x00 0x03600000 0x0 0x00100000 /* controller
> > registers */
> > > @@ -533,6 +554,16 @@
> > > status = "disabled";
> > > };
> > >
> > > + pcie_ep@3600000 {
> > > + compatible = "fsl,ls1088a-pcie-ep","fsl,ls-pcie-ep";
> > > + reg = <0x00 0x03600000 0x0 0x00100000
> > > + 0x30 0x00000000 0x8 0x00000000>;
> > > + reg-names = "regs", "addr_space";
> > > + num-ib-windows = <6>;
> > > + num-ob-windows = <8>;
> > > + status = "disabled";
> > > + };
> > > +
> > > smmu: iommu@5000000 {
> > > compatible = "arm,mmu-500";
> > > reg = <0 0x5000000 0 0x800000>;
> > > --
> > > 2.9.5
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in pci_device_id table
From: Andrew Murray @ 2019-09-12 12:59 UTC (permalink / raw)
To: Xiaowei Bao, helgaas
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <AM5PR04MB3299D598229952C13C492B48F5B90@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Tue, Sep 03, 2019 at 01:52:30AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年9月2日 20:55
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> > Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> > arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> > <zhiqiang.hou@nxp.com>
> > Subject: Re: [PATCH v3 11/11] misc: pci_endpoint_test: Add LS1088a in
> > pci_device_id table
> >
> > On Mon, Sep 02, 2019 at 11:17:16AM +0800, Xiaowei Bao wrote:
> > > Add LS1088a in pci_device_id table so that pci-epf-test can be used
> > > for testing PCIe EP in LS1088a.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - No change.
> > > v3:
> > > - No change.
> > >
> > > drivers/misc/pci_endpoint_test.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/misc/pci_endpoint_test.c
> > > b/drivers/misc/pci_endpoint_test.c
> > > index 6e208a0..d531951 100644
> > > --- a/drivers/misc/pci_endpoint_test.c
> > > +++ b/drivers/misc/pci_endpoint_test.c
> > > @@ -793,6 +793,7 @@ static const struct pci_device_id
> > pci_endpoint_test_tbl[] = {
> > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA74x) },
> > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_DRA72x) },
> > > { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x81c0) },
> > > + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, 0x80c0) },
> >
> > The Freescale PCI devices are the only devices in this table that don't have a
> > define for their device ID. I think a define should be created for both of the
> > device IDs above.
>
> OK, but I only define in this file, I am not sure this can define in include/linux/pci_ids.h
> file
This file seems a little inconsistent...
- Two of the TI device IDs are defined in pci_ids.h and only used in pci_endpoint_test.c
- One of the TI device IDs are defined in pci_endpoint_test.c and only used there
- The Freescale device ID is hardcoded and only used in pci_endpoint_test.c
The header in pci_ids.h has a comment suggestion definitions are only added where used
in multiple files - yet I don't think this holds true.
Bjorn - do you have a suggestion?
Thanks,
Andrew Murray
>
> Thanks
> Xiaowei
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > { PCI_DEVICE_DATA(SYNOPSYS, EDDA, NULL) },
> > > { PCI_DEVICE(PCI_VENDOR_ID_TI, PCI_DEVICE_ID_TI_AM654),
> > > .driver_data = (kernel_ulong_t)&am654_data
> > > --
> > > 2.9.5
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for ls1088a and ls2088a
From: Andrew Murray @ 2019-09-12 12:49 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland@arm.com, Roy Zang, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
Z.q. Hou, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, M.h. Lian, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, Leo Li, shawnguo@kernel.org,
Mingkai Hu
In-Reply-To: <AM5PR04MB329970AE2C1812E88B9DE5A2F5B90@AM5PR04MB3299.eurprd04.prod.outlook.com>
On Tue, Sep 03, 2019 at 01:47:36AM +0000, Xiaowei Bao wrote:
>
>
> > -----Original Message-----
> > From: Andrew Murray <andrew.murray@arm.com>
> > Sent: 2019年9月2日 20:46
> > To: Xiaowei Bao <xiaowei.bao@nxp.com>
> > Cc: robh+dt@kernel.org; mark.rutland@arm.com; shawnguo@kernel.org; Leo
> > Li <leoyang.li@nxp.com>; kishon@ti.com; lorenzo.pieralisi@arm.com; M.h.
> > Lian <minghuan.lian@nxp.com>; Mingkai Hu <mingkai.hu@nxp.com>; Roy
> > Zang <roy.zang@nxp.com>; jingoohan1@gmail.com;
> > gustavo.pimentel@synopsys.com; linux-pci@vger.kernel.org;
> > devicetree@vger.kernel.org; linux-kernel@vger.kernel.org;
> > linux-arm-kernel@lists.infradead.org; linuxppc-dev@lists.ozlabs.org;
> > arnd@arndb.de; gregkh@linuxfoundation.org; Z.q. Hou
> > <zhiqiang.hou@nxp.com>
> > Subject: Re: [PATCH v3 09/11] PCI: layerscape: Add EP mode support for
> > ls1088a and ls2088a
> >
> > On Mon, Sep 02, 2019 at 11:17:14AM +0800, Xiaowei Bao wrote:
> > > Add PCIe EP mode support for ls1088a and ls2088a, there are some
> > > difference between LS1 and LS2 platform, so refactor the code of the
> > > EP driver.
> > >
> > > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> > > ---
> > > v2:
> > > - This is a new patch for supporting the ls1088a and ls2088a platform.
> > > v3:
> > > - Adjust the some struct assignment order in probe function.
> > >
> > > drivers/pci/controller/dwc/pci-layerscape-ep.c | 72
> > > +++++++++++++++++++-------
> > > 1 file changed, 53 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > index 5f0cb99..723bbe5 100644
> > > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > > @@ -20,27 +20,29 @@
> > >
> > > #define PCIE_DBI2_OFFSET 0x1000 /* DBI2 base address*/
> > >
> > > -struct ls_pcie_ep {
> > > - struct dw_pcie *pci;
> > > - struct pci_epc_features *ls_epc;
> > > +#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > +
> > > +struct ls_pcie_ep_drvdata {
> > > + u32 func_offset;
> > > + const struct dw_pcie_ep_ops *ops;
> > > + const struct dw_pcie_ops *dw_pcie_ops;
> > > };
> > >
> > > -#define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> > > +struct ls_pcie_ep {
> > > + struct dw_pcie *pci;
> > > + struct pci_epc_features *ls_epc;
> > > + const struct ls_pcie_ep_drvdata *drvdata; };
> > >
> > > static int ls_pcie_establish_link(struct dw_pcie *pci) {
> > > return 0;
> > > }
> > >
> > > -static const struct dw_pcie_ops ls_pcie_ep_ops = {
> > > +static const struct dw_pcie_ops dw_ls_pcie_ep_ops = {
> > > .start_link = ls_pcie_establish_link, };
> > >
> > > -static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > - { .compatible = "fsl,ls-pcie-ep",},
> > > - { },
> > > -};
> > > -
> > > static const struct pci_epc_features* ls_pcie_ep_get_features(struct
> > > dw_pcie_ep *ep) { @@ -87,10 +89,39 @@ static int
> > > ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > > }
> > > }
> > >
> > > -static const struct dw_pcie_ep_ops pcie_ep_ops = {
> > > +static unsigned int ls_pcie_ep_func_conf_select(struct dw_pcie_ep *ep,
> > > + u8 func_no)
> > > +{
> > > + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> > > +
> > > + WARN_ON(func_no && !pcie->drvdata->func_offset);
> > > + return pcie->drvdata->func_offset * func_no; }
> > > +
> > > +static const struct dw_pcie_ep_ops ls_pcie_ep_ops = {
> > > .ep_init = ls_pcie_ep_init,
> > > .raise_irq = ls_pcie_ep_raise_irq,
> > > .get_features = ls_pcie_ep_get_features,
> > > + .func_conf_select = ls_pcie_ep_func_conf_select, };
> > > +
> > > +static const struct ls_pcie_ep_drvdata ls1_ep_drvdata = {
> > > + .ops = &ls_pcie_ep_ops,
> > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > > +};
> > > +
> > > +static const struct ls_pcie_ep_drvdata ls2_ep_drvdata = {
> > > + .func_offset = 0x20000,
> > > + .ops = &ls_pcie_ep_ops,
> > > + .dw_pcie_ops = &dw_ls_pcie_ep_ops,
> > > +};
> > > +
> > > +static const struct of_device_id ls_pcie_ep_of_match[] = {
> > > + { .compatible = "fsl,ls1046a-pcie-ep", .data = &ls1_ep_drvdata },
> > > + { .compatible = "fsl,ls1088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > + { .compatible = "fsl,ls2088a-pcie-ep", .data = &ls2_ep_drvdata },
> > > + { },
> >
> > This removes support for "fsl,ls-pcie-ep" - was that intentional? If you do plan
> > to drop it please make sure you explain why in the commit message. See also
> > my comments in your dt-binding patch.
>
> In fact, the u-boot will fixup the status property to 'status = enabled' in PCI node of
> the DTS base on "fsl,ls-pcie-ep" compatible, so "fsl,ls-pcie-ep" is used, I used this
> compatible before, because the driver only support the LS1046a, but this time, I add
> the LS1088a and LS2088a support, and these two boards have some difference form
> LS1046a, so I changed the compatible. I am not sure whether need to add "fsl,ls-pcie-ep"
> in there, could you give some advice, thanks a lot.
It sounds like "fsl,ls-pcie-ep" can be a fallback for "fsl,ls1046a-pcie-ep".
I'm assuming that if someone used "fsl,ls1046a-pcie-ep" on ls1088a or ls2088a
hardware it would still work, but without the multiple PF support.
I.e. if "fsl,ls-pcie-ep" is given, treat it as ls1046a.
Thanks,
Andrew Murray
>
> Thanks
> Xiaowei
>
> >
> > Thanks,
> >
> > Andrew Murray
> >
> > > };
> > >
> > > static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie, @@ -103,7
> > > +134,7 @@ static int __init ls_add_pcie_ep(struct ls_pcie_ep *pcie,
> > > int ret;
> > >
> > > ep = &pci->ep;
> > > - ep->ops = &pcie_ep_ops;
> > > + ep->ops = pcie->drvdata->ops;
> > >
> > > res = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "addr_space");
> > > if (!res)
> > > @@ -142,20 +173,23 @@ static int __init ls_pcie_ep_probe(struct
> > platform_device *pdev)
> > > if (!ls_epc)
> > > return -ENOMEM;
> > >
> > > - dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "regs");
> > > - pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > - if (IS_ERR(pci->dbi_base))
> > > - return PTR_ERR(pci->dbi_base);
> > > + pcie->drvdata = of_device_get_match_data(dev);
> > >
> > > - pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > pci->dev = dev;
> > > - pci->ops = &ls_pcie_ep_ops;
> > > - pcie->pci = pci;
> > > + pci->ops = pcie->drvdata->dw_pcie_ops;
> > >
> > > ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> > >
> > > + pcie->pci = pci;
> > > pcie->ls_epc = ls_epc;
> > >
> > > + dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM,
> > "regs");
> > > + pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> > > + if (IS_ERR(pci->dbi_base))
> > > + return PTR_ERR(pci->dbi_base);
> > > +
> > > + pci->dbi_base2 = pci->dbi_base + PCIE_DBI2_OFFSET;
> > > +
> > > platform_set_drvdata(pdev, pcie);
> > >
> > > ret = ls_add_pcie_ep(pcie, pdev);
> > > --
> > > 2.9.5
> > >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: imx7d: Add opp-suspend property
From: Leonard Crestez @ 2019-09-12 12:46 UTC (permalink / raw)
To: Anson Huang, shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1568256992-31707-2-git-send-email-Anson.Huang@nxp.com>
On 2019-09-12 5:57 AM, Anson Huang wrote:
> Add "opp-suspend" property for i.MX7D to make sure system
> suspend with max available opp.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] ARM: dts: imx7d: Correct speed grading fuse settings
From: Leonard Crestez @ 2019-09-12 12:45 UTC (permalink / raw)
To: Anson Huang, shawnguo@kernel.org
Cc: mark.rutland@arm.com, devicetree@vger.kernel.org,
s.hauer@pengutronix.de, linux-kernel@vger.kernel.org,
robh+dt@kernel.org, dl-linux-imx, kernel@pengutronix.de,
festevam@gmail.com, linux-arm-kernel@lists.infradead.org
In-Reply-To: <1568256992-31707-1-git-send-email-Anson.Huang@nxp.com>
On 2019-09-12 5:57 AM, Anson Huang wrote:
> The 800MHz opp speed grading fuse mask should be 0xd instead
> of 0xf according to fuse map definition:
>
> SPEED_GRADING[1:0] MHz
> 00 800
> 01 500
> 10 1000
> 11 1200
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Are you going to add the 500mhz OPP as well?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: KASAN: slab-out-of-bounds Read in handle_vmptrld
From: Will Deacon @ 2019-09-12 12:25 UTC (permalink / raw)
To: syzbot
Cc: mark.rutland, x86, wanpengli, kvm, narmstrong, catalin.marinas,
will.deacon, hpa, khilman, joro, rkrcmar, mingo, devicetree,
syzkaller-bugs, robh+dt, bp, linux-amlogic, tglx,
linux-arm-kernel, jmattson, linux-kernel, sean.j.christopherson,
carlo, pbonzini, vkuznets
In-Reply-To: <000000000000a9d4f705924cff7a@google.com>
On Wed, Sep 11, 2019 at 01:38:08PM -0700, syzbot wrote:
> syzbot found the following crash on:
>
> HEAD commit: 1e3778cb Merge tag 'scsi-fixes' of git://git.kernel.org/pu..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15bdfc5e600000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b89bb446a3faaba4
> dashboard link: https://syzkaller.appspot.com/bug?extid=46f1dd7dbbe2bfb98b10
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1709421a600000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=168fc4b2600000
>
> The bug was bisected to:
>
> commit a87f854ddcf7ff7e044d72db0aa6da82f26d69a6
> Author: Neil Armstrong <narmstrong@baylibre.com>
> Date: Wed Oct 11 15:39:40 2017 +0000
>
> ARM64: dts: meson-gx: remove unnecessary uart compatible
>
> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=17e78a6e600000
> final crash: https://syzkaller.appspot.com/x/report.txt?x=14178a6e600000
> console output: https://syzkaller.appspot.com/x/log.txt?x=10178a6e600000
Unfortunately, I think the bisect must be bogus, since I can't see how a
devicetree change for an arm64 file can affect the x86 KVM instruction
emulation.
Maybe somebody from the x86 KVM side could have a look at the KASAN splat?
Will
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+46f1dd7dbbe2bfb98b10@syzkaller.appspotmail.com
> Fixes: a87f854ddcf7 ("ARM64: dts: meson-gx: remove unnecessary uart
> compatible")
>
> L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and
> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for
> details.
> ==================================================================
> BUG: KASAN: slab-out-of-bounds in handle_vmptrld
> arch/x86/kvm/vmx/nested.c:4789 [inline]
> BUG: KASAN: slab-out-of-bounds in handle_vmptrld+0x777/0x800
> arch/x86/kvm/vmx/nested.c:4749
> Read of size 4 at addr ffff888091e10000 by task syz-executor758/10006
>
> CPU: 1 PID: 10006 Comm: syz-executor758 Not tainted 5.3.0-rc7+ #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
> __kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
> kasan_report+0x12/0x17 mm/kasan/common.c:618
> __asan_report_load_n_noabort+0xf/0x20 mm/kasan/generic_report.c:142
> handle_vmptrld arch/x86/kvm/vmx/nested.c:4789 [inline]
> handle_vmptrld+0x777/0x800 arch/x86/kvm/vmx/nested.c:4749
> vmx_handle_exit+0x299/0x15e0 arch/x86/kvm/vmx/vmx.c:5886
> vcpu_enter_guest+0x1087/0x5e90 arch/x86/kvm/x86.c:8088
> vcpu_run arch/x86/kvm/x86.c:8152 [inline]
> kvm_arch_vcpu_ioctl_run+0x464/0x1750 arch/x86/kvm/x86.c:8360
> kvm_vcpu_ioctl+0x4dc/0xfd0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:2765
> vfs_ioctl fs/ioctl.c:46 [inline]
> file_ioctl fs/ioctl.c:509 [inline]
> do_vfs_ioctl+0xdb6/0x13e0 fs/ioctl.c:696
> ksys_ioctl+0xab/0xd0 fs/ioctl.c:713
> __do_sys_ioctl fs/ioctl.c:720 [inline]
> __se_sys_ioctl fs/ioctl.c:718 [inline]
> __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:718
> do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x447269
> Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff
> 0f 83 3b d0 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007ffd58df6ad8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: ffffffffffffffda RBX: 00007ffd58df6ae0 RCX: 0000000000447269
> RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000005
> RBP: 0000000000000000 R08: 0000000020003800 R09: 0000000000400e80
> R10: 00007ffd58df4f20 R11: 0000000000000246 R12: 0000000000404730
> R13: 00000000004047c0 R14: 0000000000000000 R15: 0000000000000000
>
> Allocated by task 10006:
> save_stack+0x23/0x90 mm/kasan/common.c:69
> set_track mm/kasan/common.c:77 [inline]
> __kasan_kmalloc mm/kasan/common.c:493 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:466
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:507
> __do_kmalloc mm/slab.c:3655 [inline]
> __kmalloc+0x163/0x770 mm/slab.c:3664
> kmalloc include/linux/slab.h:557 [inline]
> hcd_buffer_alloc+0x1c6/0x260 drivers/usb/core/buffer.c:132
> usb_alloc_coherent+0x62/0x90 drivers/usb/core/usb.c:910
> usbdev_mmap+0x1ce/0x790 drivers/usb/core/devio.c:224
> call_mmap include/linux/fs.h:1875 [inline]
> mmap_region+0xc35/0x1760 mm/mmap.c:1788
> do_mmap+0x82e/0x1090 mm/mmap.c:1561
> do_mmap_pgoff include/linux/mm.h:2374 [inline]
> vm_mmap_pgoff+0x1c5/0x230 mm/util.c:391
> ksys_mmap_pgoff+0x4aa/0x630 mm/mmap.c:1611
> __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
> __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
> do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 9516:
> save_stack+0x23/0x90 mm/kasan/common.c:69
> set_track mm/kasan/common.c:77 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:455
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:463
> __cache_free mm/slab.c:3425 [inline]
> kfree+0x10a/0x2c0 mm/slab.c:3756
> tomoyo_init_log+0x15ba/0x2070 security/tomoyo/audit.c:293
> tomoyo_supervisor+0x33f/0xef0 security/tomoyo/common.c:2095
> tomoyo_audit_env_log security/tomoyo/environ.c:36 [inline]
> tomoyo_env_perm+0x18e/0x210 security/tomoyo/environ.c:63
> tomoyo_environ security/tomoyo/domain.c:670 [inline]
> tomoyo_find_next_domain+0x1354/0x1f6c security/tomoyo/domain.c:876
> tomoyo_bprm_check_security security/tomoyo/tomoyo.c:107 [inline]
> tomoyo_bprm_check_security+0x124/0x1b0 security/tomoyo/tomoyo.c:97
> security_bprm_check+0x63/0xb0 security/security.c:750
> search_binary_handler+0x71/0x570 fs/exec.c:1645
> exec_binprm fs/exec.c:1701 [inline]
> __do_execve_file.isra.0+0x1333/0x2340 fs/exec.c:1821
> do_execveat_common fs/exec.c:1868 [inline]
> do_execve fs/exec.c:1885 [inline]
> __do_sys_execve fs/exec.c:1961 [inline]
> __se_sys_execve fs/exec.c:1956 [inline]
> __x64_sys_execve+0x8f/0xc0 fs/exec.c:1956
> do_syscall_64+0xfd/0x6a0 arch/x86/entry/common.c:296
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff888091e109c0
> which belongs to the cache kmalloc-8k of size 8192
> The buggy address is located 2496 bytes to the left of
> 8192-byte region [ffff888091e109c0, ffff888091e129c0)
> The buggy address belongs to the page:
> page:ffffea0002478400 refcount:2 mapcount:0 mapping:ffff8880aa4021c0
> index:0x0 compound_mapcount: 0
> flags: 0x1fffc0000010200(slab|head)
> raw: 01fffc0000010200 ffffea000242e608 ffffea0002436708 ffff8880aa4021c0
> raw: 0000000000000000 ffff888091e109c0 0000000200000001 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff888091e0ff00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff888091e0ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > ffff888091e10000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ^
> ffff888091e10080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff888091e10100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> For information about bisection process see: https://goo.gl/tpsmEJ#bisection
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] imx_v6_v7_defconfig: Build USB_CONFIGFS into kernel
From: Leonard Crestez @ 2019-09-12 12:16 UTC (permalink / raw)
To: Peter Chen, Shawn Guo
Cc: Dong Aisheng, Fabio Estevam, linux-imx, kernel, linux-arm-kernel
Some imx chips don't have chips and a limited number of USB controllers.
For such cases NXP suggests configuring the USB controller as an
ethernet gadget for network boot testing.
Switch USB_CONFIGFS to be built into the kernel so that we can configure
the ethernet gadget without also deploying modules.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
---
arch/arm/configs/imx_v6_v7_defconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/configs/imx_v6_v7_defconfig b/arch/arm/configs/imx_v6_v7_defconfig
index ade4a2dd1a18..5debac5b038e 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -325,11 +325,11 @@ CONFIG_USB_TEST=m
CONFIG_USB_EHSET_TEST_FIXTURE=m
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_MXS_PHY=y
CONFIG_USB_GADGET=y
CONFIG_USB_FSL_USB2=y
-CONFIG_USB_CONFIGFS=m
+CONFIG_USB_CONFIGFS=y
CONFIG_USB_CONFIGFS_SERIAL=y
CONFIG_USB_CONFIGFS_ACM=y
CONFIG_USB_CONFIGFS_OBEX=y
CONFIG_USB_CONFIGFS_NCM=y
CONFIG_USB_CONFIGFS_ECM=y
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-09-12 12:12 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
u.kleine-koenig@pengutronix.de
In-Reply-To: <9a48ca49-4c6f-f17e-3306-6af41d3b162c@televic.com>
On 9/12/19 11:45 AM, Jurgen Lambrecht wrote:
> CAUTION: This Email originated from outside Televic. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
>
> On 9/12/19 4:06 AM, Robin Gong wrote:
>> On 2019-9-3 22:32 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote
>>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>>
>>>> On 2019-8-29 14:24, Jurgen Lambrecht wrote:
>>>>> On 8/28/19 4:05 PM, Robin Gong wrote:
>>>>>> Could you help check if below commit in your side?
>>>>>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
>>>>>> Author: Lucas Stach<l.stach@pengutronix.de>
>>>>>> Date: Tue Nov 6 03:40:28 2018 +0000
>>>>> yes, it's in.
>>>>>
>>>>> Also the 2 follow-up commits of Lucas Stach:
>>>>> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
>>>>> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
>>> I had also already cherry picked your commit
>>> 3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma:
>>> remove BD_INTR for channel0".
>>>
>>> But also then kernel hangs at loading sdma FW.
>>>
>>> (this looked the most interesting commit)
>> I identified this issue which caused by SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
>> (41)exceed the structure sdma_script_start_addrs(40) so that illegal memory
>> touch, such as slob block header, thus kernel trap into while() loop forever
>> in slob_free(). Please see the below code piece in sdma_add_scripts().
>> for (i = 0; i < sdma->script_number; i++)
>> if (addr_arr[i] > 0)
>> saddr_arr[i] = addr_arr[i];
>> That issue was brought by commit a572460be9cf (dmaengine: imx-sdma:
>> Add support for version 3 firmware) because the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
>> (38->41 3 scripts added) not align with script number added in
>> sdma_script_start_addrs(2 scripts). Please have a try with
>> the below patch:
>> diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
>> index 6eaa53c..30e676b 100644
>> --- a/include/linux/platform_data/dma-imx-sdma.h
>> +++ b/include/linux/platform_data/dma-imx-sdma.h
>> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
>> /* End of v2 array */
>> s32 zcanfd_2_mcu_addr;
>> s32 zqspi_2_mcu_addr;
>> + s32 mcu_2_ecspi_addr;
>> /* End of v3 array */
>> + s32 mcu_2_zqspi_addr;
>> + /* End of v4 array */
>> };
>>
> Yes, this patch solves it! I can now use SLOB slab allocator. I tried
> several reboots and power cycles.
> I tried with different dts (without earlycon, without sdma on uart and
> ecspi).
> I did not try other kernels, only 4.19.66+fscl with our patches and sdma
> v3.5 built-in.
I tried again v5.3 rc6 with SLOB, but it still booted OK, then took
latest v5.3 rc8 from mainline, and it also boots OK - tried several
times also with power cycle.
Then I added your patch, and it "still" boots :-). So OK:
Linux imx6ul-33927318 5.3.0-rc8-dirty #3 PREEMPT Thu Sep 12 13:54:25
CEST 2019 armv7l GNU/Linux
> Thanks and also thanks Uwe for analyzing the assembly,
>
> Jürgen
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.infradead.org%2Fmailman%2Flistinfo%2Flinux-arm-kernel&data=02%7C01%7CJ.Lambrecht%40televic.com%7C31571c624eb54b6d6dbe08d737660f66%7C68a8593ed1fc4a6ab7821bdcb0633231%7C1%7C0%7C637038783797869668&sdata=ZpzjxmupoHLuvtCF5kNBBMgXxMF6SUbnyuK7Vpq1YrM%3D&reserved=0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V2 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Anshuman Khandual @ 2019-09-12 12:09 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Gerald Schaefer, linux-snps-arc,
linux-arm-kernel, Kees Cook, Masahiro Yamada, Mark Brown,
Dan Williams, Vlastimil Babka, Christophe Leroy,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <20190912110016.srrydg2krplscbgq@box>
On 09/12/2019 04:30 PM, Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2019 at 11:32:53AM +0530, Anshuman Khandual wrote:
>> +MODULE_LICENSE("GPL v2");
>> +MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual@arm.com>");
>> +MODULE_DESCRIPTION("Test architecture page table helpers");
>
> It's not module. Why?
Not any more. Nothing in particular. Just that module_init() code gets
executed after page allocator init which is needed here. But I guess
probably not a great way to get this test started.
>
> BTW, I think we should make all code here __init (or it's variants) so it
> can be discarded on boot. It has not use after that.
Sounds good, will change. Will mark all these functions as __init and
will trigger the test with late_initcall().
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Qian Cai @ 2019-09-12 12:05 UTC (permalink / raw)
To: Sergey Senozhatsky
Cc: Petr Mladek, Theodore Ts'o, Arnd Bergmann, Peter Zijlstra,
Catalin Marinas, linux-kernel, Steven Rostedt, linux-mm,
Greg Kroah-Hartman, Waiman Long, Dan Williams, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190911011008.GA4420@jagdpanzerIV>
On Wed, 2019-09-11 at 10:10 +0900, Sergey Senozhatsky wrote:
> Cc-ing Ted, Arnd, Greg
>
> On (09/10/19 11:22), Qian Cai wrote:
> > [ 1078.283869][T43784] -> #3 (&(&port->lock)->rlock){-.-.}:
> > [ 1078.291350][T43784] __lock_acquire+0x5c8/0xbb0
> > [ 1078.296394][T43784] lock_acquire+0x154/0x428
> > [ 1078.301266][T43784] _raw_spin_lock_irqsave+0x80/0xa0
> > [ 1078.306831][T43784] tty_port_tty_get+0x28/0x68
> > [ 1078.311873][T43784] tty_port_default_wakeup+0x20/0x40
> > [ 1078.317523][T43784] tty_port_tty_wakeup+0x38/0x48
> > [ 1078.322827][T43784] uart_write_wakeup+0x2c/0x50
> > [ 1078.327956][T43784] pl011_tx_chars+0x240/0x260
> > [ 1078.332999][T43784] pl011_start_tx+0x24/0xa8
> > [ 1078.337868][T43784] __uart_start+0x90/0xa0
> > [ 1078.342563][T43784] uart_write+0x15c/0x2c8
> > [ 1078.347261][T43784] do_output_char+0x1c8/0x2b0
> > [ 1078.352304][T43784] n_tty_write+0x300/0x668
> > [ 1078.357087][T43784] tty_write+0x2e8/0x430
> > [ 1078.361696][T43784] redirected_tty_write+0xcc/0xe8
> > [ 1078.367086][T43784] do_iter_write+0x228/0x270
> > [ 1078.372041][T43784] vfs_writev+0x10c/0x1c8
> > [ 1078.376735][T43784] do_writev+0xdc/0x180
> > [ 1078.381257][T43784] __arm64_sys_writev+0x50/0x60
> > [ 1078.386476][T43784] el0_svc_handler+0x11c/0x1f0
> > [ 1078.391606][T43784] el0_svc+0x8/0xc
> > [ 1078.395691][T43784]
>
> uart_port->lock -> tty_port->lock
>
> This thing along is already a bit suspicious. We re-enter tty
> here: tty -> uart -> serial -> tty
>
> And we re-enter tty under uart_port->lock.
>
> > [ 1078.395691][T43784] -> #2 (&port_lock_key){-.-.}:
> > [ 1078.402561][T43784] __lock_acquire+0x5c8/0xbb0
> > [ 1078.407604][T43784] lock_acquire+0x154/0x428
> > [ 1078.412474][T43784] _raw_spin_lock+0x68/0x88
> > [ 1078.417343][T43784] pl011_console_write+0x2ac/0x318
> > [ 1078.422820][T43784] console_unlock+0x3c4/0x898
> > [ 1078.427863][T43784] vprintk_emit+0x2d4/0x460
> > [ 1078.432732][T43784] vprintk_default+0x48/0x58
> > [ 1078.437688][T43784] vprintk_func+0x194/0x250
> > [ 1078.442557][T43784] printk+0xbc/0xec
> > [ 1078.446732][T43784] register_console+0x4a8/0x580
> > [ 1078.451947][T43784] uart_add_one_port+0x748/0x878
> > [ 1078.457250][T43784] pl011_register_port+0x98/0x128
> > [ 1078.462639][T43784] sbsa_uart_probe+0x398/0x480
> > [ 1078.467772][T43784] platform_drv_probe+0x70/0x108
> > [ 1078.473075][T43784] really_probe+0x15c/0x5d8
> > [ 1078.477944][T43784] driver_probe_device+0x94/0x1d0
> > [ 1078.483335][T43784] __device_attach_driver+0x11c/0x1a8
> > [ 1078.489072][T43784] bus_for_each_drv+0xf8/0x158
> > [ 1078.494201][T43784] __device_attach+0x164/0x240
> > [ 1078.499331][T43784] device_initial_probe+0x24/0x30
> > [ 1078.504721][T43784] bus_probe_device+0xf0/0x100
> > [ 1078.509850][T43784] device_add+0x63c/0x960
> > [ 1078.514546][T43784] platform_device_add+0x1ac/0x3b8
> > [ 1078.520023][T43784] platform_device_register_full+0x1fc/0x290
> > [ 1078.526373][T43784] acpi_create_platform_device.part.0+0x264/0x3a8
> > [ 1078.533152][T43784] acpi_create_platform_device+0x68/0x80
> > [ 1078.539150][T43784] acpi_default_enumeration+0x34/0x78
> > [ 1078.544887][T43784] acpi_bus_attach+0x340/0x3b8
> > [ 1078.550015][T43784] acpi_bus_attach+0xf8/0x3b8
> > [ 1078.555057][T43784] acpi_bus_attach+0xf8/0x3b8
> > [ 1078.560099][T43784] acpi_bus_attach+0xf8/0x3b8
> > [ 1078.565142][T43784] acpi_bus_scan+0x9c/0x100
> > [ 1078.570015][T43784] acpi_scan_init+0x16c/0x320
> > [ 1078.575058][T43784] acpi_init+0x330/0x3b8
> > [ 1078.579666][T43784] do_one_initcall+0x158/0x7ec
> > [ 1078.584797][T43784] kernel_init_freeable+0x9a8/0xa70
> > [ 1078.590360][T43784] kernel_init+0x18/0x138
> > [ 1078.595055][T43784] ret_from_fork+0x10/0x1c
> >
> > [ 1078.599835][T43784] -> #1 (console_owner){-...}:
> > [ 1078.606618][T43784] __lock_acquire+0x5c8/0xbb0
> > [ 1078.611661][T43784] lock_acquire+0x154/0x428
> > [ 1078.616530][T43784] console_unlock+0x298/0x898
> > [ 1078.621573][T43784] vprintk_emit+0x2d4/0x460
> > [ 1078.626442][T43784] vprintk_default+0x48/0x58
> > [ 1078.631398][T43784] vprintk_func+0x194/0x250
> > [ 1078.636267][T43784] printk+0xbc/0xec
> > [ 1078.640443][T43784] _warn_unseeded_randomness+0xb4/0xd0
> > [ 1078.646267][T43784] get_random_u64+0x4c/0x100
> > [ 1078.651224][T43784] add_to_free_area_random+0x168/0x1a0
> > [ 1078.657047][T43784] free_one_page+0x3dc/0xd08
> > [ 1078.662003][T43784] __free_pages_ok+0x490/0xd00
> > [ 1078.667132][T43784] __free_pages+0xc4/0x118
> > [ 1078.671914][T43784] __free_pages_core+0x2e8/0x428
> > [ 1078.677219][T43784] memblock_free_pages+0xa4/0xec
> > [ 1078.682522][T43784] memblock_free_all+0x264/0x330
> > [ 1078.687825][T43784] mem_init+0x90/0x148
> > [ 1078.692259][T43784] start_kernel+0x368/0x684
>
> zone->lock --> uart_port->lock
>
> Some debugging options/warnings/error print outs/etc introduce
> deadlock patterns.
>
> This adds zone->lock --> uart_port->lock, which then brings in
> uart_port->lock --> tty_port->lock, which in turn brings
> tty_port->lock --> zone->lock.
>
> > [ 1078.697126][T43784] -> #0 (&(&zone->lock)->rlock){-.-.}:
> > [ 1078.704604][T43784] check_prev_add+0x120/0x1138
> > [ 1078.709733][T43784] validate_chain+0x888/0x1270
> > [ 1078.714863][T43784] __lock_acquire+0x5c8/0xbb0
> > [ 1078.719906][T43784] lock_acquire+0x154/0x428
> > [ 1078.724776][T43784] _raw_spin_lock+0x68/0x88
> > [ 1078.729645][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> > [ 1078.735643][T43784] get_page_from_freelist+0x898/0x24a0
> > [ 1078.741467][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> > [ 1078.747291][T43784] alloc_pages_current+0xb4/0x150
> > [ 1078.752682][T43784] allocate_slab+0xab8/0x2350
> > [ 1078.757725][T43784] new_slab+0x98/0xc0
> > [ 1078.762073][T43784] ___slab_alloc+0x66c/0xa30
> > [ 1078.767029][T43784] __slab_alloc+0x68/0xc8
> > [ 1078.771725][T43784] __kmalloc+0x3d4/0x658
> > [ 1078.776333][T43784] __tty_buffer_request_room+0xd4/0x220
> > [ 1078.782244][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> > [ 1078.788849][T43784] pty_write+0x98/0x100
> > [ 1078.793370][T43784] n_tty_write+0x2a0/0x668
> > [ 1078.798152][T43784] tty_write+0x2e8/0x430
> > [ 1078.802760][T43784] __vfs_write+0x5c/0xb0
> > [ 1078.807368][T43784] vfs_write+0xf0/0x230
> > [ 1078.811890][T43784] ksys_write+0xd4/0x180
> > [ 1078.816498][T43784] __arm64_sys_write+0x4c/0x60
> > [ 1078.821627][T43784] el0_svc_handler+0x11c/0x1f0
> > [ 1078.826756][T43784] el0_svc+0x8/0xc
>
> tty_port->lock --> zone->lock
>
> > [ 1078.830842][T43784] other info that might help us debug this:
> > [ 1078.830842][T43784]
> > [ 1078.840918][T43784] Chain exists of:
> > [ 1078.840918][T43784] &(&zone->lock)->rlock --> &port_lock_key --> &(&port-> >lock)->rlock
> > [ 1078.840918][T43784]
> > [ 1078.854731][T43784] Possible unsafe locking scenario:
> > [ 1078.854731][T43784]
> > [ 1078.862029][T43784] CPU0 CPU1
> > [ 1078.867243][T43784] ---- ----
> > [ 1078.872457][T43784] lock(&(&port->lock)->rlock);
> > [ 1078.877238][T43784] lock(&port_lock_key);
> > [ 1078.883929][T43784] lock(&(&port->lock)->rlock);
> > [ 1078.891228][T43784] lock(&(&zone->lock)->rlock);
> > [ 1078.896010][T43784]
> > [ 1078.896010][T43784] *** DEADLOCK ***
>
> [..]
> > [ 1078.980932][T43784] dump_backtrace+0x0/0x228
> > [ 1078.985279][T43784] show_stack+0x24/0x30
> > [ 1078.989282][T43784] dump_stack+0xe8/0x13c
> > [ 1078.993370][T43784] print_circular_bug+0x334/0x3d8
> > [ 1078.998240][T43784] check_noncircular+0x268/0x310
> > [ 1079.003022][T43784] check_prev_add+0x120/0x1138
> > [ 1079.007631][T43784] validate_chain+0x888/0x1270
> > [ 1079.012241][T43784] __lock_acquire+0x5c8/0xbb0
> > [ 1079.016763][T43784] lock_acquire+0x154/0x428
> > [ 1079.021111][T43784] _raw_spin_lock+0x68/0x88
> > [ 1079.025460][T43784] rmqueue_bulk.constprop.21+0xb0/0x1218
> > [ 1079.030937][T43784] get_page_from_freelist+0x898/0x24a0
> > [ 1079.036240][T43784] __alloc_pages_nodemask+0x2a8/0x1d08
> > [ 1079.041542][T43784] alloc_pages_current+0xb4/0x150
> > [ 1079.046412][T43784] allocate_slab+0xab8/0x2350
> > [ 1079.050934][T43784] new_slab+0x98/0xc0
> > [ 1079.054761][T43784] ___slab_alloc+0x66c/0xa30
> > [ 1079.059196][T43784] __slab_alloc+0x68/0xc8
> > [ 1079.063371][T43784] __kmalloc+0x3d4/0x658
> > [ 1079.067458][T43784] __tty_buffer_request_room+0xd4/0x220
> > [ 1079.072847][T43784] tty_insert_flip_string_fixed_flag+0x6c/0x128
> > [ 1079.078932][T43784] pty_write+0x98/0x100
> > [ 1079.082932][T43784] n_tty_write+0x2a0/0x668
> > [ 1079.087193][T43784] tty_write+0x2e8/0x430
> > [ 1079.091280][T43784] __vfs_write+0x5c/0xb0
> > [ 1079.095367][T43784] vfs_write+0xf0/0x230
> > [ 1079.099368][T43784] ksys_write+0xd4/0x180
> > [ 1079.103455][T43784] __arm64_sys_write+0x4c/0x60
> > [ 1079.108064][T43784] el0_svc_handler+0x11c/0x1f0
> > [ 1079.112672][T43784] el0_svc+0x8/0xc
>
> tty_port->lock --> zone->lock
>
> For instance, I don't really like the re-entrant tty, at least not
> under uart_port->lock. This, maybe, can be one of the solutions.
>
> Another one, a quick and dirty one, (and so many people will blame
> me for this) would be to break zone->{printk}->uart chain...
>
> Something like this
>
> ---
>
> drivers/char/random.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 9b54cdb301d3..975015857200 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1687,8 +1687,9 @@ static void _warn_unseeded_randomness(const char *func_name, void *caller,
> print_once = true;
> #endif
> if (__ratelimit(&unseeded_warning))
> - pr_notice("random: %s called from %pS with crng_init=%d\n",
> - func_name, caller, crng_init);
> + printk_deferred(KERN_NOTICE "random: %s called from %pS "
> + "with crng_init=%d\n", func_name, caller,
> + crng_init);
> }
>
> /*
> @@ -2462,4 +2463,4 @@ void add_bootloader_randomness(const void *buf, unsigned int size)
> else
> add_device_randomness(buf, size);
> }
> -EXPORT_SYMBOL_GPL(add_bootloader_randomness);
> \ No newline at end of file
> +EXPORT_SYMBOL_GPL(add_bootloader_randomness);
This will also fix the hang.
Sergey, do you plan to submit this Ted?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/13] KVM: Refactor error handling for setting memory region
From: Janosch Frank @ 2019-09-12 11:36 UTC (permalink / raw)
To: Sean Christopherson, James Hogan, Paul Mackerras,
Christian Borntraeger, Paolo Bonzini, Radim Krčmář,
Marc Zyngier
Cc: Julien Thierry, Wanpeng Li, kvm, David Hildenbrand, Joerg Roedel,
Cornelia Huck, linux-mips, kvm-ppc, linux-kernel, James Morse,
linux-arm-kernel, Vitaly Kuznetsov, kvmarm, Suzuki K Pouloze,
Jim Mattson
In-Reply-To: <20190911185038.24341-6-sean.j.christopherson@intel.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 4009 bytes --]
On 9/11/19 8:50 PM, Sean Christopherson wrote:
> Replace a big pile o' gotos with returns to make it more obvious what
> error code is being returned, and to prepare for refactoring the
> functional, i.e. post-checks, portion of __kvm_set_memory_region().
>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Definitely necessary
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
> ---
> virt/kvm/kvm_main.c | 40 ++++++++++++++++++----------------------
> 1 file changed, 18 insertions(+), 22 deletions(-)
>
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ea8f2f37096f..8306ce3345a6 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -929,34 +929,33 @@ int __kvm_set_memory_region(struct kvm *kvm,
>
> r = check_memory_region_flags(mem);
> if (r)
> - goto out;
> + return r;
>
> - r = -EINVAL;
> as_id = mem->slot >> 16;
> id = (u16)mem->slot;
>
> /* General sanity checks */
> if (mem->memory_size & (PAGE_SIZE - 1))
> - goto out;
> + return -EINVAL;
> if (mem->guest_phys_addr & (PAGE_SIZE - 1))
> - goto out;
> + return -EINVAL;
> /* We can read the guest memory with __xxx_user() later on. */
> if ((id < KVM_USER_MEM_SLOTS) &&
> ((mem->userspace_addr & (PAGE_SIZE - 1)) ||
> !access_ok((void __user *)(unsigned long)mem->userspace_addr,
> mem->memory_size)))
> - goto out;
> + return -EINVAL;
> if (as_id >= KVM_ADDRESS_SPACE_NUM || id >= KVM_MEM_SLOTS_NUM)
> - goto out;
> + return -EINVAL;
> if (mem->guest_phys_addr + mem->memory_size < mem->guest_phys_addr)
> - goto out;
> + return -EINVAL;
>
> slot = id_to_memslot(__kvm_memslots(kvm, as_id), id);
> base_gfn = mem->guest_phys_addr >> PAGE_SHIFT;
> npages = mem->memory_size >> PAGE_SHIFT;
>
> if (npages > KVM_MEM_MAX_NR_PAGES)
> - goto out;
> + return -EINVAL;
>
> new = old = *slot;
>
> @@ -973,20 +972,18 @@ int __kvm_set_memory_region(struct kvm *kvm,
> if ((new.userspace_addr != old.userspace_addr) ||
> (npages != old.npages) ||
> ((new.flags ^ old.flags) & KVM_MEM_READONLY))
> - goto out;
> + return -EINVAL;
>
> if (base_gfn != old.base_gfn)
> change = KVM_MR_MOVE;
> else if (new.flags != old.flags)
> change = KVM_MR_FLAGS_ONLY;
> - else { /* Nothing to change. */
> - r = 0;
> - goto out;
> - }
> + else /* Nothing to change. */
> + return 0;
> }
> } else {
> if (!old.npages)
> - goto out;
> + return -EINVAL;
>
> change = KVM_MR_DELETE;
> new.base_gfn = 0;
> @@ -995,29 +992,29 @@ int __kvm_set_memory_region(struct kvm *kvm,
>
> if ((change == KVM_MR_CREATE) || (change == KVM_MR_MOVE)) {
> /* Check for overlaps */
> - r = -EEXIST;
> kvm_for_each_memslot(slot, __kvm_memslots(kvm, as_id)) {
> if (slot->id == id)
> continue;
> if (!((base_gfn + npages <= slot->base_gfn) ||
> (base_gfn >= slot->base_gfn + slot->npages)))
> - goto out;
> + return -EEXIST;
> }
> }
>
> - r = -ENOMEM;
> -
> /* Allocate/free page dirty bitmap as needed */
> if (!(new.flags & KVM_MEM_LOG_DIRTY_PAGES))
> new.dirty_bitmap = NULL;
> else if (!new.dirty_bitmap) {
> - if (kvm_create_dirty_bitmap(&new) < 0)
> - goto out;
> + r = kvm_create_dirty_bitmap(&new);
> + if (r)
> + return r;
> }
>
> slots = kvzalloc(sizeof(struct kvm_memslots), GFP_KERNEL_ACCOUNT);
> - if (!slots)
> + if (!slots) {
> + r = -ENOMEM;
> goto out_bitmap;
> + }
> memcpy(slots, __kvm_memslots(kvm, as_id), sizeof(struct kvm_memslots));
>
> if ((change == KVM_MR_DELETE) || (change == KVM_MR_MOVE)) {
> @@ -1068,7 +1065,6 @@ int __kvm_set_memory_region(struct kvm *kvm,
> out_bitmap:
> if (new.dirty_bitmap && !old.dirty_bitmap)
> kvm_destroy_dirty_bitmap(&new);
> -out:
> return r;
> }
> EXPORT_SYMBOL_GPL(__kvm_set_memory_region);
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v9 0/8] stg mail -e --version=v9 \
From: Nitesh Narayan Lal @ 2019-09-12 12:00 UTC (permalink / raw)
To: David Hildenbrand, Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev, Rik van Riel,
Matthew Wilcox, Wang, Wei W, ying.huang, Konrad Rzeszutek Wilk,
Dan Williams, linux-arm-kernel, Oscar Salvador, Dave Hansen, LKML,
Paolo Bonzini, Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <ef460202-cebd-c6d2-19f3-e8a82a3d3cbd@redhat.com>
On 9/12/19 3:47 AM, David Hildenbrand wrote:
> On 12.09.19 09:16, Michal Hocko wrote:
>> On Wed 11-09-19 18:09:18, David Hildenbrand wrote:
>>> On 11.09.19 15:51, Michal Hocko wrote:
>>>> On Wed 11-09-19 15:20:02, Michal Hocko wrote:
>>>> [...]
>>>>>> 4. Continuously report, not the "one time report everything" approach.
>>>>> So you mean the allocator reporting this rather than an external code to
>>>>> poll right? I do not know, how much this is nice to have than must have?
>>>> Another idea that I haven't really thought through so it might turned
>>>> out to be completely bogus but let's try anyway. Your "report everything"
>>>> just made me look and realize that free_pages_prepare already performs
>>>> stuff that actually does something similar yet unrelated.
>>>>
>>>> We do report to special page poisoning, zeroying or
>>>> CONFIG_DEBUG_PAGEALLOC to unmap the address from the kernel address
>>>> space. This sounds like something fitting your model no?
>>>>
>>> AFAIKS, the poisoning/unmapping is done whenever a page is freed. I
>>> don't quite see yet how that would help to remember if a page was
>>> already reported.
>> Do you still have to differ that state when each page is reported?
> Ah, very good point. I can see that the reason for this was not
> discussed in this thread so far. (Alexander, Nitesh, please correct me
> if I am wrong). It's buried in the long history of free page
> hinting/reporting.
>
> Some early patch sets tried to report during every free synchronously.
> Free a page, report them to the hypervisor. This resulted in some issues
> (especially, locking-related and the virtio + the hypervisor being
> involved, resulting in unpredictable delays, quite some overhead ...).
> It was no good.
+1
If I remember correctly then Alexander had posted a patch-set
prior to this series where he was reporting every page of a fixed
order from __free_one_page(). But as you said it will be costly as
it will involve one hypercall per page of reporting_order.
>
> One design decision then was to not report single pages, but a bunch of
> pages at once. This made it necessary to "remember" the pages to be
> reported and to temporarily block them from getting allocated while
> reporting.
Until my v7 posting [1] I was doing this. We did not proceed with
this as blocking allocation was not recommended for reporting.
>
> Nitesh implemented (at least) two "capture PFNs of free pages in an
> array when freeing" approaches. One being synchronous from the freeing
> CPU once the list was full (having similar issues as plain synchronous
> reporting) and one being asynchronous by a separate thread (which solved
> many locking issues).
One issue with asynchronous + array approach was that it could have lead
to false OOMs due to several pages being isolated at the same time.
>
> Turned out the a simple array can quickly lead to us having to drop
> "reports" to the hypervisor because the array is full and the reporting
> thread was not able to keep up. Not good as well. Especially, if some
> process frees a lot of memory this can happen quickly and Nitesh wa
> sable to trigger this scenario frequently.
+1
>
> Finally, Nitesh decided to use the bitmap instead to keep track of pages
> to report. I'd like to note that this approach could still be combined
> with an "array of potentially free PFNs". Only when the array/circular
> buffer runs out of entries ("reporting thread cannot keep up"), we would
> have to go back to scanning the bitmap.
I will have to think about it.
> That was also the point where Alexander decided to look into integrating
> tracking/handling reported/unreported pages directly in the buddy.
>
>>> After reporting the page we would have to switch some
>>> state (Nitesh: bitmap bit, Alexander: page flag) to identify that.
>> Yes, you can either store the state somewhere.
>>
>>> Of course, we could map the page and treat that as "the state" when we
>>> reported it, but I am not sure that's such a good idea :)
>>>
>>> As always, I might be very wrong ...
>> I still do not fully understand the usecase so I might be equally wrong.
>> My thinking is along these lines. Why should you scan free pages when
>> you can effectively capture each freed page? If you go one step further
>> then post_alloc_hook would be the counterpart to know that your page has
>> been allocated.
> I'd like to note that Nitesh's patch set contains the following hunk,
> which is roughly what you were thinking :)
>
>
> -static inline void __free_one_page(struct page *page,
> +inline void __free_one_page(struct page *page,
> unsigned long pfn,
> struct zone *zone, unsigned int order,
> - int migratetype)
> + int migratetype, bool hint)
> {
> unsigned long combined_pfn;
> unsigned long uninitialized_var(buddy_pfn);
> @@ -980,7 +981,8 @@ static inline void __free_one_page(struct page *page,
> migratetype);
> else
> add_to_free_area(page, &zone->free_area[order], migratetype);
> -
> + if (hint)
> + page_hinting_enqueue(page, order);
> }
>
>
> (ignore the hint parameter, when he would switch to a isolate vs.
> alloc/free, that can go away and all we left is the enqueue part)
Precisely.
Although, there would be a scenario where the allocation will
take place for a page whose order would be < REPORTING_ORDER.
In that case, if I decide to ignore all the remaining pages and clear
the previously head free page bit, I might end
up losing the reporting opportunity.
But I can certainly look into this.
>
>
> Inside that callback we can remember the pages any way we want. Right
> now in a bitmap. Maybe later in a array + bitmap (as discussed above).
> Another idea I had was to simply go over all pages and report them when
> running into this "array full" condition. But I am not yet sure about
> the performance implications on rather large machines. So the bitmap
> idea might have some other limitations but seems to do its job.
That's correct, I was actually trying to come up with a basic framework.
Which is acceptable in terms of benefits and performance and that can fit into
most of the use-cases (if not all).
After which my plan was to further optimize it.
>
> Hoe that makes things clearer and am not missing something.
Thanks for explaining.
>
--
Thanks
Nitesh
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv5 10/10] ARM: OMAP2+: pdata-quirks: add PRM data for reset support
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
The parent clockdomain for reset must be in force wakeup mode, otherwise
the reset may never complete. Add pdata quirks for this purpose for PRM
driver.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 6c6f8fce854e..4730f8c0cb0e 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -25,6 +25,7 @@
#include <linux/platform_data/ti-sysc.h>
#include <linux/platform_data/wkup_m3.h>
#include <linux/platform_data/asoc-ti-mcbsp.h>
+#include <linux/platform_data/ti-prm.h>
#include "clockdomain.h"
#include "common.h"
@@ -565,6 +566,12 @@ void omap_pcs_legacy_init(int irq, void (*rearm)(void))
pcs_pdata.rearm = rearm;
}
+static struct ti_prm_platform_data ti_prm_pdata = {
+ .clkdm_deny_idle = clkdm_deny_idle,
+ .clkdm_allow_idle = clkdm_allow_idle,
+ .clkdm_lookup = clkdm_lookup,
+};
+
/*
* GPIOs for TWL are initialized by the I2C bus and need custom
* handing until DSS has device tree bindings.
@@ -664,6 +671,11 @@ static struct of_dev_auxdata omap_auxdata_lookup[] = {
/* Common auxdata */
OF_DEV_AUXDATA("ti,sysc", 0, NULL, &ti_sysc_pdata),
OF_DEV_AUXDATA("pinctrl-single", 0, NULL, &pcs_pdata),
+ OF_DEV_AUXDATA("ti,omap4-prm-inst", 0, NULL, &ti_prm_pdata),
+ OF_DEV_AUXDATA("ti,omap5-prm-inst", 0, NULL, &ti_prm_pdata),
+ OF_DEV_AUXDATA("ti,dra7-prm-inst", 0, NULL, &ti_prm_pdata),
+ OF_DEV_AUXDATA("ti,am3-prm-inst", 0, NULL, &ti_prm_pdata),
+ OF_DEV_AUXDATA("ti,am4-prm-inst", 0, NULL, &ti_prm_pdata),
{ /* sentinel */ },
};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 09/10] soc: ti: omap-prm: add omap5 PRM data
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add PRM instance data for omap5 family of SoCs. Initially this is just
used to provide reset support.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 73ea64896770..38e8704c51ad 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -84,6 +84,14 @@ static const struct omap_prm_data omap4_prm_data[] = {
{ },
};
+static const struct omap_prm_data omap5_prm_data[] = {
+ { .name = "dsp", .base = 0x4ae06400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "core", .base = 0x4ae06700, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ipu", .rstmap = rst_map_012 },
+ { .name = "iva", .base = 0x4ae07200, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012 },
+ { .name = "device", .base = 0x4ae07c00, .rstctrl = 0x0, .rstst = 0x4, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ { },
+};
+
static const struct omap_prm_data dra7_prm_data[] = {
{ .name = "dsp1", .base = 0x4ae06400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
{ .name = "ipu", .base = 0x4ae06500, .rstctrl = 0x10, .rstst = 0x14, .clkdm_name = "ipu1", .rstmap = rst_map_012 },
@@ -136,6 +144,7 @@ static const struct omap_prm_data am4_prm_data[] = {
static const struct of_device_id omap_prm_id_table[] = {
{ .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
+ { .compatible = "ti,omap5-prm-inst", .data = omap5_prm_data },
{ .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
{ .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
{ .compatible = "ti,am4-prm-inst", .data = am4_prm_data },
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 08/10] soc: ti: omap-prm: add am4 PRM data
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add PRM instance data for am4 family of SoCs. Initially this is just
used to provide reset support.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index de11ce08ff7b..73ea64896770 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -115,10 +115,30 @@ static const struct omap_prm_data am3_prm_data[] = {
{ },
};
+static const struct omap_rst_map am4_per_rst_map[] = {
+ { .rst = 1, .st = 0 },
+ { .rst = -1 },
+};
+
+static const struct omap_rst_map am4_device_rst_map[] = {
+ { .rst = 0, .st = 1 },
+ { .rst = 1, .st = 0 },
+ { .rst = -1 },
+};
+
+static const struct omap_prm_data am4_prm_data[] = {
+ { .name = "gfx", .base = 0x44df0400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+ { .name = "per", .base = 0x44df0800, .rstctrl = 0x10, .rstst = 0x14, .rstmap = am4_per_rst_map, .clkdm_name = "pruss_ocp" },
+ { .name = "wkup", .base = 0x44df2000, .rstctrl = 0x10, .rstst = 0x14, .rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_NO_CLKDM },
+ { .name = "device", .base = 0x44df4000, .rstctrl = 0x0, .rstst = 0x4, .rstmap = am4_device_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ { },
+};
+
static const struct of_device_id omap_prm_id_table[] = {
{ .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
{ .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
{ .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
+ { .compatible = "ti,am4-prm-inst", .data = am4_prm_data },
{ },
};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 07/10] soc: ti: omap-prm: add dra7 PRM data
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add PRM instance data for dra7 family of SoCs. Initially this is just
used to provide reset support.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index a5fde34f6afd..de11ce08ff7b 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -84,6 +84,19 @@ static const struct omap_prm_data omap4_prm_data[] = {
{ },
};
+static const struct omap_prm_data dra7_prm_data[] = {
+ { .name = "dsp1", .base = 0x4ae06400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "ipu", .base = 0x4ae06500, .rstctrl = 0x10, .rstst = 0x14, .clkdm_name = "ipu1", .rstmap = rst_map_012 },
+ { .name = "core", .base = 0x4ae06700, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ipu2", .rstmap = rst_map_012 },
+ { .name = "iva", .base = 0x4ae06f00, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012 },
+ { .name = "dsp2", .base = 0x4ae07b00, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "eve1", .base = 0x4ae07b40, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "eve2", .base = 0x4ae07b80, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "eve3", .base = 0x4ae07bc0, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "eve4", .base = 0x4ae07c00, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { },
+};
+
static const struct omap_rst_map am3_per_rst_map[] = {
{ .rst = 1 },
{ .rst = -1 },
@@ -104,6 +117,7 @@ static const struct omap_prm_data am3_prm_data[] = {
static const struct of_device_id omap_prm_id_table[] = {
{ .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
+ { .compatible = "ti,dra7-prm-inst", .data = dra7_prm_data },
{ .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
{ },
};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 06/10] soc: ti: omap-prm: add data for am33xx
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add PRM instance data for AM33xx SoC. Includes some basic register
definitions and reset data for now.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 24 ++++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 24b1da3492c0..a5fde34f6afd 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -58,6 +58,11 @@ struct omap_reset_data {
#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
+static const struct omap_rst_map rst_map_0[] = {
+ { .rst = 0, .st = 0 },
+ { .rst = -1 },
+};
+
static const struct omap_rst_map rst_map_01[] = {
{ .rst = 0, .st = 0 },
{ .rst = 1, .st = 1 },
@@ -79,8 +84,27 @@ static const struct omap_prm_data omap4_prm_data[] = {
{ },
};
+static const struct omap_rst_map am3_per_rst_map[] = {
+ { .rst = 1 },
+ { .rst = -1 },
+};
+
+static const struct omap_rst_map am3_wkup_rst_map[] = {
+ { .rst = 3, .st = 5 },
+ { .rst = -1 },
+};
+
+static const struct omap_prm_data am3_prm_data[] = {
+ { .name = "per", .base = 0x44e00c00, .rstctrl = 0x0, .rstmap = am3_per_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL, .clkdm_name = "pruss_ocp" },
+ { .name = "wkup", .base = 0x44e00d00, .rstctrl = 0x0, .rstst = 0xc, .rstmap = am3_wkup_rst_map, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ { .name = "device", .base = 0x44e00f00, .rstctrl = 0x0, .rstst = 0x8, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ { .name = "gfx", .base = 0x44e01100, .rstctrl = 0x4, .rstst = 0x14, .rstmap = rst_map_0, .clkdm_name = "gfx_l3" },
+ { },
+};
+
static const struct of_device_id omap_prm_id_table[] = {
{ .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
+ { .compatible = "ti,am3-prm-inst", .data = am3_prm_data },
{ },
};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 05/10] soc: ti: omap-prm: add omap4 PRM data
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add PRM data for omap4 family of SoCs. Initially this is just used to
provide reset support.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 3d9393ff67e3..24b1da3492c0 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -58,7 +58,29 @@ struct omap_reset_data {
#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
+static const struct omap_rst_map rst_map_01[] = {
+ { .rst = 0, .st = 0 },
+ { .rst = 1, .st = 1 },
+ { .rst = -1 },
+};
+
+static const struct omap_rst_map rst_map_012[] = {
+ { .rst = 0, .st = 0 },
+ { .rst = 1, .st = 1 },
+ { .rst = 2, .st = 2 },
+ { .rst = -1 },
+};
+
+static const struct omap_prm_data omap4_prm_data[] = {
+ { .name = "tesla", .base = 0x4a306400, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_01 },
+ { .name = "core", .base = 0x4a306700, .rstctrl = 0x210, .rstst = 0x214, .clkdm_name = "ducati", .rstmap = rst_map_012 },
+ { .name = "ivahd", .base = 0x4a306f00, .rstctrl = 0x10, .rstst = 0x14, .rstmap = rst_map_012 },
+ { .name = "device", .base = 0x4a307b00, .rstctrl = 0x0, .rstst = 0x4, .rstmap = rst_map_01, .flags = OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_NO_CLKDM },
+ { },
+};
+
static const struct of_device_id omap_prm_id_table[] = {
+ { .compatible = "ti,omap4-prm-inst", .data = omap4_prm_data },
{ },
};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 01/10] dt-bindings: omap: add new binding for PRM instances
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add new binding for OMAP PRM (Power and Reset Manager) instances. Each
of these will act as a power domain controller and potentially as a reset
provider.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
v5: - dropped the clocks property as the dependency towards clocks was
removed
- changed the name of the node to be power-controller
.../devicetree/bindings/arm/omap/prm-inst.txt | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/prm-inst.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/prm-inst.txt b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
new file mode 100644
index 000000000000..942f7aac3b00
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/prm-inst.txt
@@ -0,0 +1,27 @@
+OMAP PRM instance bindings
+
+Power and Reset Manager is an IP block on OMAP family of devices which
+handle the power domains and their current state, and provide reset
+handling for the domains and/or separate IP blocks under the power domain
+hierarchy.
+
+Required properties:
+- compatible: Must be one of:
+ "ti,am3-prm-inst"
+ "ti,am4-prm-inst"
+ "ti,omap4-prm-inst"
+ "ti,omap5-prm-inst"
+ "ti,dra7-prm-inst"
+- reg: Contains PRM instance register address range
+ (base address and length)
+
+Optional properties:
+- #reset-cells: Should be 1 if the PRM instance in question supports resets.
+
+Example:
+
+prm_dsp2: power-controller@1b00 {
+ compatible = "ti,dra7-prm-inst";
+ reg = <0x1b00 0x40>;
+ #reset-cells = <1>;
+};
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 02/10] soc: ti: add initial PRM driver with reset control support
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Add initial PRM (Power and Reset Management) driver for TI OMAP class
SoCs. Initially this driver only supports reset control, but can be
extended to support rest of the functionality, like powerdomain
control, PRCM irq support etc.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
drivers/soc/ti/Makefile | 1 +
drivers/soc/ti/omap_prm.c | 259 ++++++++++++++++++++++++++++++++++++
3 files changed, 261 insertions(+)
create mode 100644 drivers/soc/ti/omap_prm.c
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index fdb6743760a2..ad08d470a2ca 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
select TI_SYSC
select OMAP_IRQCHIP
select CLKSRC_TI_32K
+ select ARCH_HAS_RESET_CONTROLLER
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
index b3868d392d4f..788b5cd1e180 100644
--- a/drivers/soc/ti/Makefile
+++ b/drivers/soc/ti/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
obj-$(CONFIG_AMX3_PM) += pm33xx.o
+obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
new file mode 100644
index 000000000000..ab0b66ad715d
--- /dev/null
+++ b/drivers/soc/ti/omap_prm.c
@@ -0,0 +1,259 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * OMAP2+ PRM driver
+ *
+ * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
+ * Tero Kristo <t-kristo@ti.com>
+ */
+
+#include <linux/kernel.h>
+#include <linux/device.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/reset-controller.h>
+#include <linux/delay.h>
+
+struct omap_rst_map {
+ s8 rst;
+ s8 st;
+};
+
+struct omap_prm_data {
+ u32 base;
+ const char *name;
+ u16 rstctrl;
+ u16 rstst;
+ const struct omap_rst_map *rstmap;
+ u8 flags;
+};
+
+struct omap_prm {
+ const struct omap_prm_data *data;
+ void __iomem *base;
+};
+
+struct omap_reset_data {
+ struct reset_controller_dev rcdev;
+ struct omap_prm *prm;
+ u32 mask;
+ spinlock_t lock; /* Protect register access */
+};
+
+#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
+
+#define OMAP_MAX_RESETS 8
+#define OMAP_RESET_MAX_WAIT 10000
+
+#define OMAP_PRM_HAS_RSTCTRL BIT(0)
+#define OMAP_PRM_HAS_RSTST BIT(1)
+
+#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
+
+static const struct of_device_id omap_prm_id_table[] = {
+ { },
+};
+
+static bool _is_valid_reset(struct omap_reset_data *reset, unsigned long id)
+{
+ if (reset->mask & BIT(id))
+ return true;
+
+ return false;
+}
+
+static int omap_reset_get_st_bit(struct omap_reset_data *reset,
+ unsigned long id)
+{
+ const struct omap_rst_map *map = reset->prm->data->rstmap;
+
+ while (map->rst >= 0) {
+ if (map->rst == id)
+ return map->st;
+
+ map++;
+ }
+
+ return id;
+}
+
+static int omap_reset_status(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+ int st_bit = omap_reset_get_st_bit(reset, id);
+ bool has_rstst = reset->prm->data->rstst ||
+ (reset->prm->data->flags & OMAP_PRM_HAS_RSTST);
+
+ /* Check if we have rstst */
+ if (!has_rstst)
+ return -ENOTSUPP;
+
+ /* Check if hw reset line is asserted */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
+ if (v & BIT(id))
+ return 1;
+
+ /*
+ * Check reset status, high value means reset sequence has been
+ * completed successfully so we can return 0 here (reset deasserted)
+ */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
+ v >>= st_bit;
+ v &= 1;
+
+ return !v;
+}
+
+static int omap_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+ unsigned long flags;
+
+ /* assert the reset control line */
+ spin_lock_irqsave(&reset->lock, flags);
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
+ v |= 1 << id;
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
+ spin_unlock_irqrestore(&reset->lock, flags);
+
+ return 0;
+}
+
+static int omap_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+ u32 v;
+ int st_bit;
+ bool has_rstst;
+ unsigned long flags;
+
+ has_rstst = reset->prm->data->rstst ||
+ (reset->prm->data->flags & OMAP_PRM_HAS_RSTST);
+
+ if (has_rstst) {
+ st_bit = omap_reset_get_st_bit(reset, id);
+
+ /* Clear the reset status by writing 1 to the status bit */
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
+ v |= 1 << st_bit;
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
+ }
+
+ /* de-assert the reset control line */
+ spin_lock_irqsave(&reset->lock, flags);
+ v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
+ v &= ~(1 << id);
+ writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
+ spin_unlock_irqrestore(&reset->lock, flags);
+
+ return 0;
+}
+
+static const struct reset_control_ops omap_reset_ops = {
+ .assert = omap_reset_assert,
+ .deassert = omap_reset_deassert,
+ .status = omap_reset_status,
+};
+
+static int omap_prm_reset_xlate(struct reset_controller_dev *rcdev,
+ const struct of_phandle_args *reset_spec)
+{
+ struct omap_reset_data *reset = to_omap_reset_data(rcdev);
+
+ if (!_is_valid_reset(reset, reset_spec->args[0]))
+ return -EINVAL;
+
+ return reset_spec->args[0];
+}
+
+static int omap_prm_reset_init(struct platform_device *pdev,
+ struct omap_prm *prm)
+{
+ struct omap_reset_data *reset;
+ const struct omap_rst_map *map;
+
+ /*
+ * Check if we have controllable resets. If either rstctrl is non-zero
+ * or OMAP_PRM_HAS_RSTCTRL flag is set, we have reset control register
+ * for the domain.
+ */
+ if (!prm->data->rstctrl && !(prm->data->flags & OMAP_PRM_HAS_RSTCTRL))
+ return 0;
+
+ map = prm->data->rstmap;
+ if (!map)
+ return -EINVAL;
+
+ reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
+ if (!reset)
+ return -ENOMEM;
+
+ reset->rcdev.owner = THIS_MODULE;
+ reset->rcdev.ops = &omap_reset_ops;
+ reset->rcdev.of_node = pdev->dev.of_node;
+ reset->rcdev.nr_resets = OMAP_MAX_RESETS;
+ reset->rcdev.of_xlate = omap_prm_reset_xlate;
+ reset->rcdev.of_reset_n_cells = 1;
+ spin_lock_init(&reset->lock);
+
+ reset->prm = prm;
+
+ while (map->rst >= 0) {
+ reset->mask |= BIT(map->rst);
+ map++;
+ }
+
+ return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
+}
+
+static int omap_prm_probe(struct platform_device *pdev)
+{
+ struct resource *res;
+ const struct omap_prm_data *data;
+ struct omap_prm *prm;
+ const struct of_device_id *match;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENODEV;
+
+ match = of_match_device(omap_prm_id_table, &pdev->dev);
+ if (!match)
+ return -ENOTSUPP;
+
+ prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
+ if (!prm)
+ return -ENOMEM;
+
+ data = match->data;
+
+ while (data->base != res->start) {
+ if (!data->base)
+ return -EINVAL;
+ data++;
+ }
+
+ prm->data = data;
+
+ prm->base = devm_ioremap_resource(&pdev->dev, res);
+ if (!prm->base)
+ return -ENOMEM;
+
+ return omap_prm_reset_init(pdev, prm);
+}
+
+static struct platform_driver omap_prm_driver = {
+ .probe = omap_prm_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .of_match_table = omap_prm_id_table,
+ },
+};
+builtin_platform_driver(omap_prm_driver);
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 04/10] soc: ti: omap-prm: add support for denying idle for reset clockdomain
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
TI SoCs hardware reset signals require the parent clockdomain to be
in force wakeup mode while de-asserting the reset, otherwise it may
never complete. To support this, add pdata hooks to control the
clockdomain directly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 36 ++++++++++++++++++++++++++--
include/linux/platform_data/ti-prm.h | 21 ++++++++++++++++
2 files changed, 55 insertions(+), 2 deletions(-)
create mode 100644 include/linux/platform_data/ti-prm.h
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index 96fa2aad9b93..3d9393ff67e3 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -16,6 +16,8 @@
#include <linux/reset-controller.h>
#include <linux/delay.h>
+#include <linux/platform_data/ti-prm.h>
+
struct omap_rst_map {
s8 rst;
s8 st;
@@ -24,6 +26,7 @@ struct omap_rst_map {
struct omap_prm_data {
u32 base;
const char *name;
+ const char *clkdm_name;
u16 rstctrl;
u16 rstst;
const struct omap_rst_map *rstmap;
@@ -40,6 +43,8 @@ struct omap_reset_data {
struct omap_prm *prm;
u32 mask;
spinlock_t lock;
+ struct clockdomain *clkdm;
+ struct device *dev;
};
#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
@@ -49,6 +54,7 @@ struct omap_reset_data {
#define OMAP_PRM_HAS_RSTCTRL BIT(0)
#define OMAP_PRM_HAS_RSTST BIT(1)
+#define OMAP_PRM_HAS_NO_CLKDM BIT(2)
#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
@@ -133,6 +139,8 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
int st_bit;
bool has_rstst;
unsigned long flags;
+ struct ti_prm_platform_data *pdata = dev_get_platdata(reset->dev);
+ int ret = 0;
has_rstst = reset->prm->data->rstst ||
(reset->prm->data->flags & OMAP_PRM_HAS_RSTST);
@@ -146,6 +154,9 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
}
+ if (reset->clkdm)
+ pdata->clkdm_deny_idle(reset->clkdm);
+
/* de-assert the reset control line */
spin_lock_irqsave(&reset->lock, flags);
v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
@@ -154,7 +165,7 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
spin_unlock_irqrestore(&reset->lock, flags);
if (!has_rstst)
- return 0;
+ goto exit;
/* wait for the status to be set */
ret = readl_relaxed_poll_timeout(reset->prm->base +
@@ -165,7 +176,11 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
pr_err("%s: timedout waiting for %s:%lu\n", __func__,
reset->prm->data->name, id);
- return 0;
+exit:
+ if (reset->clkdm)
+ pdata->clkdm_allow_idle(reset->clkdm);
+
+ return ret;
}
static const struct reset_control_ops omap_reset_ops = {
@@ -190,6 +205,8 @@ static int omap_prm_reset_init(struct platform_device *pdev,
{
struct omap_reset_data *reset;
const struct omap_rst_map *map;
+ struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ char buf[32];
/*
* Check if we have controllable resets. If either rstctrl is non-zero
@@ -199,6 +216,11 @@ static int omap_prm_reset_init(struct platform_device *pdev,
if (!prm->data->rstctrl && !(prm->data->flags & OMAP_PRM_HAS_RSTCTRL))
return 0;
+ /* Check if we have the pdata callbacks in place */
+ if (!pdata || !pdata->clkdm_lookup || !pdata->clkdm_deny_idle ||
+ !pdata->clkdm_allow_idle)
+ return -EINVAL;
+
map = prm->data->rstmap;
if (!map)
return -EINVAL;
@@ -213,10 +235,20 @@ static int omap_prm_reset_init(struct platform_device *pdev,
reset->rcdev.nr_resets = OMAP_MAX_RESETS;
reset->rcdev.of_xlate = omap_prm_reset_xlate;
reset->rcdev.of_reset_n_cells = 1;
+ reset->dev = &pdev->dev;
spin_lock_init(&reset->lock);
reset->prm = prm;
+ sprintf(buf, "%s_clkdm", prm->data->clkdm_name ? prm->data->clkdm_name :
+ prm->data->name);
+
+ if (!(prm->data->flags & OMAP_PRM_HAS_NO_CLKDM)) {
+ reset->clkdm = pdata->clkdm_lookup(buf);
+ if (!reset->clkdm)
+ return -EINVAL;
+ }
+
while (map->rst >= 0) {
reset->mask |= BIT(map->rst);
map++;
diff --git a/include/linux/platform_data/ti-prm.h b/include/linux/platform_data/ti-prm.h
new file mode 100644
index 000000000000..28154c3226c2
--- /dev/null
+++ b/include/linux/platform_data/ti-prm.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * TI PRM (Power & Reset Manager) platform data
+ *
+ * Copyright (C) 2019 Texas Instruments, Inc.
+ *
+ * Tero Kristo <t-kristo@ti.com>
+ */
+
+#ifndef _LINUX_PLATFORM_DATA_TI_PRM_H
+#define _LINUX_PLATFORM_DATA_TI_PRM_H
+
+struct clockdomain;
+
+struct ti_prm_platform_data {
+ void (*clkdm_deny_idle)(struct clockdomain *clkdm);
+ void (*clkdm_allow_idle)(struct clockdomain *clkdm);
+ struct clockdomain * (*clkdm_lookup)(const char *name);
+};
+
+#endif /* _LINUX_PLATFORM_DATA_TI_PRM_H */
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCHv5 03/10] soc: ti: omap-prm: poll for reset complete during de-assert
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Poll for reset completion status during de-assertion of reset, otherwise
the IP in question might be accessed before it has left reset properly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index ab0b66ad715d..96fa2aad9b93 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -153,6 +153,18 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
spin_unlock_irqrestore(&reset->lock, flags);
+ if (!has_rstst)
+ return 0;
+
+ /* wait for the status to be set */
+ ret = readl_relaxed_poll_timeout(reset->prm->base +
+ reset->prm->data->rstst,
+ v, v & BIT(st_bit), 1,
+ OMAP_RESET_MAX_WAIT);
+ if (ret)
+ pr_err("%s: timedout waiting for %s:%lu\n", __func__,
+ reset->prm->data->name, id);
+
return 0;
}
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox