* RE: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Andy Duan @ 2019-08-07 1:50 UTC (permalink / raw)
To: Srinivas Kandagatla, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: gregkh@linuxfoundation.org, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <65afeaaf-f703-02f2-a918-90a8bb8f58b6@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Sent: Tuesday, August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.duan@nxp.com wrote:
> > From: Fugang Duan <fugang.duan@nxp.com>
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
Thanks for your review.
I will send the V2 version including the separated device tree bindings patch.
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: "of/platform: Pause/resume sync state during init and of_platform_populate()" with a warning on arm64
From: Qian Cai @ 2019-08-07 1:56 UTC (permalink / raw)
To: Saravana Kannan
Cc: Greg Kroah-Hartman, Rob Herring, Linux List Kernel Mailing,
linux-arm-kernel,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS
In-Reply-To: <CAGETcx_KZNMY1Zs=G=HGPfsUA4Fen_m8R4L9jNHtWrZerabwxg@mail.gmail.com>
> On Aug 6, 2019, at 9:50 PM, Saravana Kannan <saravanak@google.com> wrote:
>
> Thanks for confirming. I didn't think ARM64 could even boot without
> DT. I'll send a fix right away.
>
> Any chance you can let us know what device this was tested on?
It is a HPE Apollo 70 arm64 server.
https://h20195.www2.hpe.com/v2/gethtml.aspx?docname=a00039978enw
>
> -Saravana
>
>
>
> -Saravana
>
> On Tue, Aug 6, 2019 at 6:46 PM Qian Cai <cai@lca.pw> wrote:
>>
>>
>>
>>> On Aug 6, 2019, at 9:22 PM, Saravana Kannan <saravanak@google.com> wrote:
>>>
>>> On Tue, Aug 6, 2019 at 5:46 PM Qian Cai <cai@lca.pw> wrote:
>>>>
>>>> It looks like the linux-next commit “of/platform: Pause/resume sync state during init and of_platform_populate()” [1]
>>>> Introduced a warning while booting arm64.
>>>>
>>>> [1] https://lore.kernel.org/lkml/20190731221721.187713-6-saravanak@google.com/
>>>>
>>>> [ 93.449300][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>>>> [ 93.464873][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for cmdq
>>>> [ 93.485481][ T1] arm-smmu-v3 arm-smmu-v3.4.auto: allocated 524288 entries for evtq
>>>> [ 93.496320][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: option mask 0x2
>>>> [ 93.502917][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: ias 44-bit, oas 44-bit (features 0x0000170d)
>>>> [ 93.621818][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for cmdq
>>>> [ 93.643000][ T1] arm-smmu-v3 arm-smmu-v3.5.auto: allocated 524288 entries for evtq
>>>> [ 94.519445][ T1] libphy: Fixed MDIO Bus: probed
>>>> [ 94.524649][ T1] EFI Variables Facility v0.08 2004-May-17
>>>> [ 94.601166][ T1] NET: Registered protocol family 17
>>>> [ 94.766008][ T1] zswap: loaded using pool lzo/zbud
>>>> [ 94.774745][ T1] kmemleak: Kernel memory leak detector initialized (mempool size: 16384)
>>>> [ 94.774756][ T1699] kmemleak: Automatic memory scanning thread started
>>>> [ 94.812338][ T1368] pcieport 0000:0f:00.0: Adding to iommu group 0
>>>> [ 94.984466][ T1] ------------[ cut here ]------------
>>>> [ 94.989827][ T1] Unmatched sync_state pause/resume!
>>>> [ 94.989894][ T1] WARNING: CPU: 25 PID: 1 at drivers/base/core.c:691 device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.006062][ T1] Modules linked in:
>>>> [ 95.009815][ T1] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 5.3.0-rc3-next-20190806+ #11
>>>> [ 95.018161][ T1] Hardware name: HPE Apollo 70 /C01_APACHE_MB , BIOS L50_5.13_1.11 06/18/2019
>>>> [ 95.028593][ T1] pstate: 60400009 (nZCv daif +PAN -UAO)
>>>> [ 95.034077][ T1] pc : device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.041124][ T1] lr : device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.048167][ T1] sp : 34ff800806e6fbc0
>>>> [ 95.052172][ T1] x29: 34ff800806e6fc00 x28: 0000000000000000
>>>> [ 95.058177][ T1] x27: 0000000000000000 x26: 0000000000000000
>>>> [ 95.064181][ T1] x25: 0000000000000038 x24: 0000000000000000
>>>> [ 95.070185][ T1] x23: 0000000000000000 x22: 0000000000000019
>>>> [ 95.076189][ T1] x21: 0000000000000000 x20: f9ff808b804e6c50
>>>> [ 95.082193][ T1] x19: ffff100014a6e600 x18: 0000000000000040
>>>> [ 95.088197][ T1] x17: 0000000000000000 x16: 86ff80099d581b50
>>>> [ 95.094201][ T1] x15: 0000000000000000 x14: ffff100010086d1c
>>>> [ 95.100205][ T1] x13: ffff1000109d8688 x12: ffffffffffffffff
>>>> [ 95.106209][ T1] x11: 00000000000000f9 x10: ffff0808b804e6c6
>>>> [ 95.112213][ T1] x9 : 4b71ad522c851d00 x8 : 4b71ad522c851d00
>>>> [ 95.118217][ T1] x7 : 6170206574617473 x6 : ffff100014076972
>>>> [ 95.124221][ T1] x5 : 34ff800806e6f8f0 x4 : 000000000000000f
>>>> [ 95.130225][ T1] x3 : ffff1000101bfa5c x2 : 0000000000000001
>>>> [ 95.136229][ T1] x1 : 0000000000000001 x0 : 0000000000000022
>>>> [ 95.142233][ T1] Call trace:
>>>> [ 95.145374][ T1] device_links_supplier_sync_state_resume+0x100/0x128
>>>> [ 95.152074][ T1] of_platform_sync_state_init+0x10/0x1c
>>>> [ 95.157557][ T1] do_one_initcall+0x2f8/0x600
>>>> [ 95.162172][ T1] do_initcall_level+0x37c/0x3fc
>>>> [ 95.166959][ T1] do_basic_setup+0x34/0x4c
>>>> [ 95.171313][ T1] kernel_init_freeable+0x188/0x24c
>>>> [ 95.176363][ T1] kernel_init+0x18/0x334
>>>> [ 95.180543][ T1] ret_from_fork+0x10/0x18
>>>> [ 95.184809][ T1] ---[ end trace a9ea68c902540fe5 ]---
>>>> [ 95.269085][ T1] Freeing unused kernel memory: 28672K
>>>> [ 101.069860][ T1] Checked W+X mappings: passed, no W+X pages found
>>>> [ 101.076265][ T1] Run /init as init process
>>>> [ 101.186359][ T1] systemd[1]: System time before build time, advancing clock.
>>>
>>>
>>> I tested it again on my device (on an older kernel) and I don't see
>>> this warning. Is this on an ARM64 target without a populated DT?
>>
>> Probably, /sys/firmware/devicetree is all empty.
>>
>>> That's the only thing I can see that could cause this warning.
>>>
>>> This is literally the code with the matching pause/resume. I can't
>>> think of any other way the pause/resume could have ended up not
>>> matching.
>>>
>>> static int __init of_platform_default_populate_init(void)
>>> {
>>> struct device_node *node;
>>>
>>> if (!of_have_populated_dt())
>>> return -ENODEV;
>>>
>>> platform_bus_type.add_links = of_link_to_suppliers;
>>> device_links_supplier_sync_state_pause(); <=========== PAUSE
>>> /*
>>> * Handle certain compatibles explicitly, since we don't want to create
>>> * platform_devices for every node in /reserved-memory with a
>>> * "compatible",
>>> */
>>> for_each_matching_node(node, reserved_mem_matches)
>>> of_platform_device_create(node, NULL, NULL);
>>>
>>> node = of_find_node_by_path("/firmware");
>>> if (node) {
>>> of_platform_populate(node, NULL, NULL, NULL);
>>> of_node_put(node);
>>> }
>>>
>>> /* Populate everything else. */
>>> of_platform_default_populate(NULL, NULL, NULL);
>>>
>>> return 0;
>>> }
>>> arch_initcall_sync(of_platform_default_populate_init);
>>>
>>> static int __init of_platform_sync_state_init(void)
>>> {
>>> device_links_supplier_sync_state_resume(); <========= RESUME
>>> return 0;
>>> }
>>> late_initcall_sync(of_platform_sync_state_init);
>>>
>>> Thanks,
>>> Saravana
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC,v3 7/9] media: platform: Add Mediatek ISP P1 device driver
From: Jungo Lin @ 2019-08-07 2:11 UTC (permalink / raw)
To: Tomasz Figa
Cc: devicetree, Sean Cheng (鄭昇弘),
Mauro Carvalho Chehab, Rynn Wu (吳育恩),
srv_heupstream, Rob Herring, Ryan Yu (余孟修),
Frankie Chiu (邱文凱), Hans Verkuil,
Matthias Brugger, Sj Huang,
moderated list:ARM/Mediatek SoC support, Laurent Pinchart,
ddavenport, Frederic Chen (陳俊元),
list@263.net:IOMMU DRIVERS <iommu@lists.linux-foundation.org>, Joerg Roedel <joro@8bytes.org>,,
Linux Media Mailing List
In-Reply-To: <CAAFQd5D5m=gGViSY++r5uUS1+91y9=Gpcss1dEXrin_T07H+uQ@mail.gmail.com>
Hi, Tomasz:
On Tue, 2019-08-06 at 18:47 +0900, Tomasz Figa wrote:
> Hi Jungo,
>
> On Fri, Jul 26, 2019 at 4:24 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> >
> > Hi, Tomasz:
> >
> > On Thu, 2019-07-25 at 18:23 +0900, Tomasz Figa wrote:
> > > .Hi Jungo,
> > >
> > > On Sat, Jul 20, 2019 at 6:58 PM Jungo Lin <jungo.lin@mediatek.com> wrote:
> > > >
> > > > Hi, Tomasz:
> > > >
> > > > On Wed, 2019-07-10 at 18:56 +0900, Tomasz Figa wrote:
> > > > > Hi Jungo,
> > > > >
> > > > > On Tue, Jun 11, 2019 at 11:53:42AM +0800, Jungo Lin wrote:
> [snip]
I just keep some questions to be clarified.
[snip]
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + } else {
> > > > > > + if (irq_status & SOF_INT_ST) {
> > > > > > + isp_dev->current_frame = hw_frame_num;
> > > > > > + isp_dev->meta0_vb2_index = meta0_vb2_index;
> > > > > > + isp_dev->meta1_vb2_index = meta1_vb2_index;
> > > > > > + }
> > > > > > + irq_handle_notify_event(isp_dev, irq_status, dma_status, 1);
> > > > > > + }
> > > > >
> > > > > The if and else blocks do almost the same things just in different order. Is
> > > > > it really expected?
> > > > >
> > > >
> > > > If we receive HW_PASS1_DON_ST & SOF_INT_ST IRQ events at the same time,
> > > > the correct sequence should be handle HW_PASS1_DON_ST firstly to check
> > > > any de-queued frame and update the next frame setting later.
> > > > Normally, this is a corner case or system performance issue.
> > >
> > > So it sounds like HW_PASS1_DON_ST means that all data from current
> > > frame has been written, right? If I understand your explanation above
> > > correctly, that would mean following handling of each interrupt:
> > >
> > > HW_PASS1_DON_ST:
> > > - CQ executes with next CQ buffer to prepare for next frame. <- how
> > > is this handled? does the CQ hardware automatically receive this event
> > > from the ISP hadware?
> > > - return VB2 buffers,
> > > - complete requests.
> > >
> > > SOF_INT_ST:
> > > - send VSYNC event to userspace,
> > > - program next CQ buffer to CQ,
> > >
> > > SW_PASS1_DON_ST:
> > > - reclaim CQ buffer and enqueue next frame to composing if available
> > >
> >
> > Sorry for our implementation of HW_PASS1_DON_ST.
> > It is confusing.
> > Below is the revised version based on your conclusion.
> > So in our new implemmenation, we just handle SOF_INT_ST &
> > SW_PASS1_DON_ST events. We just add one warning message for
> > HW_PASS1_DON_ST
> >
> > HW_PASS1_DON_ST:
> > - CQ executes with next CQ buffer to prepare for next frame.
> >
> > SOF_INT_ST:
> > - send VSYNC event to userspace,
> > - program next CQ buffer to CQ,
> >
> > SW_PASS1_DON_ST:
> > - reclaim CQ buffer and enqueue next frame to composing if available
> > - return VB2 buffers,
> > - complete requests.
> >
> > For CQ HW operations, it is listed below:
> >
> > a. The CQ buffer has two kinds of information
> > - Which ISP registers needs to be updated.
> > - Where the corresponding ISP register data to be read.
> > b. The CQ buffer loading procedure is triggered by HW_PASS1_DONT_ST IRQ
> > event periodically.
> > - Normally, if the ISP HW receives the completed frame and it will
> > trigger W_PASS1_DONT_ST IRQ and perform CQ buffer loading immediately.
> > - So the CQ buffer loading is performed by ISP HW automatically.
> > c. The ISP HW will read CQ base address register(REG_CQ_THR0_BASEADDR)
> > to decide which CQ buffer is loaded.
> > - So we configure the next CQ base address in SOF.
> > d. For CQ buffer loading, CQ will read the ISP registers from CQ buffer
> > and update the ISP register values into HW.
> > - SCP composer will compose one dummy CQ buffer and assign it to
> > REG_CQ_THR0_BASEADDR of each CQ buffer.
> > - Dummy CQ buffer has no updated ISP registers comparing with other
> > CQ buffers.
> > - With this design, if there is no updated new CQ buffer by driver
> > which may be caused no en-queue frames from user space. The CQ HW will
> > load dummy CQ buffer and do nothing.
>
> Does the set of registers programmed by CQ include destination buffer
> addresses to? If yes, we would end up overwriting previous frames if
> no new buffers are provided.
>
Yes, the buffer addresses are changed per frame request. We need to
compose CQ to include these DMA destination addresses. For your concern,
we have DMA flow buffer control (FBC) in HW. If there is no FBC counter
increased due to no buffer for each DMA, the ISP HW doesn't output the
data to the corresponding DMA address.
Below is the simple descriptor of CQ buffer.
a. ISP registers in tuning buffer, including 3A registers.
b. All capture buffers informations.
- DMA buffer destination address
- FBC counter
c. Some specif ISP registers for meta DMAs, such as LCE or LMVO.
d. frame sequence number register
> > f. The CQ buffer loading is guaranteed by HW to finish before the next
> > SOF.
> >
>
> Okay, thanks a lot for the explanation. This is much more clear now.
>
> [snip]
> > > > > > +static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > > > + SET_SYSTEM_SLEEP_PM_OPS(mtk_isp_suspend, mtk_isp_resume)
> > > > > > + SET_RUNTIME_PM_OPS(mtk_isp_suspend, mtk_isp_resume, NULL)
> > > > >
> > > > > For V4L2 drivers system and runtime PM ops would normally be completely
> > > > > different. Runtime PM ops would be called when the hardware is idle already
> > > > > or is about to become active. System PM ops would be called at system power
> > > > > state change and the hardware might be both idle or active. Please also see
> > > > > my comments to mtk_isp_suspend() and mtk_isp_resume() above.
> > > > >
> > > >
> > > > Here is the new implementation. It should be clear to show the
> > > > difference between system and runtime PM ops.
> > > >
> > > > static const struct dev_pm_ops mtk_isp_pm_ops = {
> > > > SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
> > > > pm_runtime_force_resume)
> > > > SET_RUNTIME_PM_OPS(mtk_isp_runtime_suspend, mtk_isp_runtime_resume,
> > > > NULL)
> > > > };
> > >
> > > That's still not correct. In runtime suspend/resume ops we already are
> > > not streaming anymore, because we call pm_runtime_get/put_*() when
> > > starting and stopping streaming. In system suspend/resume ops we might
> > > be streaming and that's when we need to stop the hardware and wait for
> > > it to finish. Please implement these ops separately.
> > >
> > > Best regards,
> > > Tomasz
> >
> >
> > Ok, got your point.
> > Below is the new implementation for your review.
> >
> > static int mtk_isp_pm_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Check ISP is streaming or not */
> > if (!p1_dev->cam_dev.streaming)
> > goto done;
>
> We would normally check here for pm_runtime_suspended(). Although they
> both should be equivalent. Still, there is no need to call
> pm_runtime_force_suspend() if the latter is true, so we could just
> return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Disable ISP's view finder and wait for TG idle */
dev_dbg(dev, "cam suspend, disable VF\n");
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val & (~TG_VF_CON_VFDATA_EN), p1_dev->regs + REG_TG_VF_CON);
ret = readl_poll_timeout_atomic(p1_dev->regs + REG_TG_INTER_ST, val,
(val & TG_CS_MASK) == TG_IDLE_ST,
USEC_PER_MSEC, MTK_ISP_STOP_HW_TIMEOUT);
if (ret)
dev_warn(dev, "can't stop HW:%d:0x%x\n", ret, val);
/* Disable CMOS */
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val & (~TG_SEN_MODE_CMOS_EN), p1_dev->regs + REG_TG_SEN_MODE);
/* Force ISP HW to idle */
ret = pm_runtime_force_suspend(dev);
if (ret)
return ret;
return 0;
}
[snip]
> > static int mtk_isp_pm_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > u32 val;
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > /* Force ISP HW to resume if needed */
> > ret = pm_runtime_force_resume(dev);
> > if (ret)
> > return ret;
>
> We should do this conditionally based on what pm_runtime_suspended()
> returns. If it's non-zero then we can just return 0 instantly.
>
Ok, here is the fixed version.
static int mtk_isp_pm_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
u32 val;
int ret;
dev_dbg(dev, "- %s\n", __func__);
if (pm_runtime_suspended(dev))
return 0;
/* Force ISP HW to resume */
ret = pm_runtime_force_resume(dev);
if (ret)
return ret;
/* Enable CMOS */
dev_dbg(dev, "cam resume, enable CMOS/VF\n");
val = readl(p1_dev->regs + REG_TG_SEN_MODE);
writel(val | TG_SEN_MODE_CMOS_EN, p1_dev->regs + REG_TG_SEN_MODE);
/* Enable VF */
val = readl(p1_dev->regs + REG_TG_VF_CON);
writel(val | TG_VF_CON_VFDATA_EN, p1_dev->regs + REG_TG_VF_CON);
return 0;
}
[snip]
> > static int mtk_isp_runtime_suspend(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> Sorry, I guess I wasn't clear in my reply. It's not possible to get
> this callback called if the device is already runtime suspended.
>
Ok, got it. Need to remove pm_runtime_suspended(dev) checking and move
it into mtk_isp_pm_* functions. If I still don't get your point, could
you kindly provide one sample driver for reference? Based on current
implementation, it is similar to below drivers.
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/mtk-mdp/mtk_mdp_core.c#L255
https://elixir.bootlin.com/linux/latest/source/drivers/media/platform/exynos4-is/fimc-is-i2c.c#L113
static int mtk_isp_runtime_suspend(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
dev_dbg(dev, "%s:disable clock\n", __func__);
clk_bulk_disable_unprepare(p1_dev->num_clks, p1_dev->clks);
return 0;
}
[snip]
> > static int mtk_isp_runtime_resume(struct device *dev)
> > {
> > struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
> > int ret;
> >
> > dev_dbg(dev, "- %s\n", __func__);
> >
> > if (pm_runtime_suspended(dev))
> > return 0;
>
> In this case the above call would always return non-zero, so the
> behavior wouldn't be very good.
>
Same as above.
static int mtk_isp_runtime_resume(struct device *dev)
{
struct mtk_isp_p1_device *p1_dev = dev_get_drvdata(dev);
int ret;
dev_dbg(dev, "%s:enable clock\n", __func__);
ret = clk_bulk_prepare_enable(p1_dev->num_clks, p1_dev->clks);
if (ret) {
dev_err(dev, "failed to enable clock:%d\n", ret);
return ret;
}
return 0;
}
Thanks for your further comments on these issues.
Best regards,
Jugno
> Best regards,
> Tomasz
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] gpio: mpc8xxx: Add new platforms GPIO DT node description
From: Hui Song @ 2019-08-07 2:12 UTC (permalink / raw)
To: Shawn Guo, Li Yang, Rob Herring, Mark Rutland, Linus Walleij,
Bartosz Golaszewski
Cc: devicetree, Song Hui, linux-kernel, linux-arm-kernel, linux-gpio
From: Song Hui <hui.song_1@nxp.com>
Update the NXP GPIO node dt-binding file for QorIQ and
Layerscape platforms, and add one more example with
ls1028a GPIO node.
Signed-off-by: Song Hui <hui.song_1@nxp.com>
---
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
index 69d4616..baf95d9 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
@@ -4,7 +4,7 @@ Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq,
- ls1021a, ls1043a, ls2080a.
+ ls1021a, ls1043a, ls2080a, ls1028a.
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
@@ -37,3 +37,17 @@ gpio0: gpio@2300000 {
interrupt-controller;
#interrupt-cells = <2>;
};
+
+
+Example of gpio-controller node for a ls1028a SoC:
+
+gpio1: gpio@2300000 {
+ compatible = "fsl,ls1028a-gpio","fsl,qoriq-gpio";
+ reg = <0x0 0x2300000 0x0 0x10000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ little-endian;
+};
--
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 related
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-07 2:39 UTC (permalink / raw)
To: Robin Murphy
Cc: Mark Rutland, devicetree, Jared D . McNeill, Maxime Ripard,
Chen-Yu Tsai, Rob Herring, Harald Geyer, arm-linux
In-Reply-To: <36e60078-7dd5-9c07-ffa1-6092d8c70fa8@arm.com>
On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
>
> On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> >>
> >> Vasily Khoruzhick writes:
> >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> >>>>
> >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> >>>>> as result 'perf top' shows no events.
> >>>>
> >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> >>>> It could well just be that the interrupt numbers are wrong...
> >>>
> >>> Looks like it does, at least result looks plausible:
> >>
> >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> >>
> >> Unfortunately I wasn't aware that perf stat is a poor test for
> >> the interrupts part of the node, when I added it. So I'm not too
> >> surprised I got it wrong.
> >>
> >> However, it would be unfortunate if the node got removed completely,
> >> because perf stat would not work anymore. Maybe we can only remove
> >> the interrupts or just fix them even if the HW doesn't work?
> >
> > I'm not familiar with PMU driver. Is it possible to get it working
> > without interrupts?
>
> Yup - you get a grumpy message from the driver, it will refuse sampling
> events (the ones which weren't working anyway), and if you measure
> anything for long enough that a counter overflows you'll get wonky
> results. But for counting hardware events over relatively short periods
> it'll still do the job.
I tried to drop interrupts completely from the node but 'perf top' is
still broken. Though now in different way: it complains "cycles: PMU
Hardware doesn't support sampling/overflow-interrupts. Try 'perf
stat'"
Is there any way to make it working?
>
> Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] xilinx_sdfec: Convert to IDA
From: Matthew Wilcox @ 2019-08-07 2:50 UTC (permalink / raw)
To: Michal Simek
Cc: linux-arm-kernel, Greg Kroah-Hartman, Arnd Bergmann,
Matthew Wilcox (Oracle), linux-kernel
From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
This driver does not use the lookup abilities of the IDR, so convert it
to the more space-efficient IDA.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
---
drivers/misc/xilinx_sdfec.c | 25 ++++++-------------------
1 file changed, 6 insertions(+), 19 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index f257d3812110..071b26a8c6a9 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xilinx_sdfec.c
@@ -22,8 +22,7 @@
#define DEV_NAME_LEN 12
-static struct idr dev_idr;
-static struct mutex dev_idr_lock;
+static DEFINE_IDA(dev_nrs);
/**
* struct xsdfec_clks - For managing SD-FEC clocks
@@ -227,13 +226,6 @@ static void xsdfec_disable_all_clks(struct xsdfec_clks *clks)
clk_disable_unprepare(clks->axi_clk);
}
-static void xsdfec_idr_remove(struct xsdfec_dev *xsdfec)
-{
- mutex_lock(&dev_idr_lock);
- idr_remove(&dev_idr, xsdfec->dev_id);
- mutex_unlock(&dev_idr_lock);
-}
-
static int xsdfec_probe(struct platform_device *pdev)
{
struct xsdfec_dev *xsdfec;
@@ -263,9 +255,7 @@ static int xsdfec_probe(struct platform_device *pdev)
/* Save driver private data */
platform_set_drvdata(pdev, xsdfec);
- mutex_lock(&dev_idr_lock);
- err = idr_alloc(&dev_idr, xsdfec->dev_name, 0, 0, GFP_KERNEL);
- mutex_unlock(&dev_idr_lock);
+ err = ida_alloc(&dev_nrs, GFP_KERNEL);
if (err < 0)
goto err_xsdfec_dev;
xsdfec->dev_id = err;
@@ -278,12 +268,12 @@ static int xsdfec_probe(struct platform_device *pdev)
err = misc_register(&xsdfec->miscdev);
if (err) {
dev_err(dev, "error:%d. Unable to register device", err);
- goto err_xsdfec_idr;
+ goto err_xsdfec_ida;
}
return 0;
-err_xsdfec_idr:
- xsdfec_idr_remove(xsdfec);
+err_xsdfec_ida:
+ ida_free(&dev_nrs, xsdfec->dev_id);
err_xsdfec_dev:
xsdfec_disable_all_clks(&xsdfec->clks);
return err;
@@ -295,7 +285,7 @@ static int xsdfec_remove(struct platform_device *pdev)
xsdfec = platform_get_drvdata(pdev);
misc_deregister(&xsdfec->miscdev);
- xsdfec_idr_remove(xsdfec);
+ ida_free(&dev_nrs, xsdfec->dev_id);
xsdfec_disable_all_clks(&xsdfec->clks);
return 0;
}
@@ -321,8 +311,6 @@ static int __init xsdfec_init(void)
{
int err;
- mutex_init(&dev_idr_lock);
- idr_init(&dev_idr);
err = platform_driver_register(&xsdfec_driver);
if (err < 0) {
pr_err("%s Unabled to register SDFEC driver", __func__);
@@ -334,7 +322,6 @@ static int __init xsdfec_init(void)
static void __exit xsdfec_exit(void)
{
platform_driver_unregister(&xsdfec_driver);
- idr_destroy(&dev_idr);
}
module_init(xsdfec_init);
--
2.20.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
* [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Tao Zhou @ 2019-08-07 2:56 UTC (permalink / raw)
To: amd-gfx, alexander.deucher, hawking.zhang, dennis.li, broonie,
akpm, christian.koenig
Cc: Tao Zhou, linux-next, linux-arm-kernel, kernel-build-reports
readq/writeq are not supported on all architectures
Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 558fe6d091ed..7eb9e0b9235a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
*/
uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
{
- uint64_t ret;
-
if ((reg * 4) < adev->rmmio_size)
- ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
+ return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
else
BUG();
-
- return ret;
}
/**
@@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
{
if ((reg * 4) < adev->rmmio_size)
- writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
+ atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
else
BUG();
}
--
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: [PATCH] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Jisheng Zhang @ 2019-08-07 3:09 UTC (permalink / raw)
To: Tao Zhou
Cc: linux-arm-kernel@lists.infradead.org,
kernel-build-reports@lists.linaro.org,
amd-gfx@lists.freedesktop.org, broonie@kernel.org,
linux-next@vger.kernel.org, alexander.deucher@amd.com,
akpm@linux-foundation.org, christian.koenig@amd.com,
dennis.li@amd.com, hawking.zhang@amd.com
In-Reply-To: <20190807025640.682-1-tao.zhou1@amd.com>
On Wed, 7 Aug 2019 10:56:40 +0800 Tao Zhou wrote:
>
>
> readq/writeq are not supported on all architectures
>
> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 558fe6d091ed..7eb9e0b9235a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> */
> uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> {
> - uint64_t ret;
> -
> if ((reg * 4) < adev->rmmio_size)
> - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
atomic64_read doesn't equal to readq on some architectures..
> else
> BUG();
> -
> - return ret;
> }
>
> /**
> @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> {
> if ((reg * 4) < adev->rmmio_size)
> - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> else
> BUG();
> }
> --
> 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
* [PATCH v2 2/4] perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
The kernel is using CAP_SYS_ADMIN instead of euid==0 to override
perf_event_paranoid check. Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/evsel.c | 2 +-
5 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/perf/arch/arm/util/cs-etm.c b/tools/perf/arch/arm/util/cs-etm.c
index 5cb07e8cb296..b87a1ca2968f 100644
--- a/tools/perf/arch/arm/util/cs-etm.c
+++ b/tools/perf/arch/arm/util/cs-etm.c
@@ -18,6 +18,7 @@
#include "../../perf.h"
#include "../../util/auxtrace.h"
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evlist.h"
#include "../../util/evsel.h"
#include "../../util/pmu.h"
@@ -254,7 +255,7 @@ static int cs_etm_recording_options(struct auxtrace_record *itr,
struct perf_pmu *cs_etm_pmu = ptr->cs_etm_pmu;
struct evsel *evsel, *cs_etm_evsel = NULL;
struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = (geteuid() == 0 || perf_event_paranoid() < 0);
+ bool privileged = perf_event_paranoid_check(-1);
int err = 0;
ptr->evlist = evlist;
diff --git a/tools/perf/arch/arm64/util/arm-spe.c b/tools/perf/arch/arm64/util/arm-spe.c
index 00915b8fd05b..200bc973371b 100644
--- a/tools/perf/arch/arm64/util/arm-spe.c
+++ b/tools/perf/arch/arm64/util/arm-spe.c
@@ -12,6 +12,7 @@
#include <time.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -65,8 +66,7 @@ static int arm_spe_recording_options(struct auxtrace_record *itr,
struct arm_spe_recording *sper =
container_of(itr, struct arm_spe_recording, itr);
struct perf_pmu *arm_spe_pmu = sper->arm_spe_pmu;
- struct evsel *evsel, *arm_spe_evsel = NULL;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
struct evsel *tracking_evsel;
int err;
diff --git a/tools/perf/arch/x86/util/intel-bts.c b/tools/perf/arch/x86/util/intel-bts.c
index 7b23318ebd7b..56a76142e9fd 100644
--- a/tools/perf/arch/x86/util/intel-bts.c
+++ b/tools/perf/arch/x86/util/intel-bts.c
@@ -12,6 +12,7 @@
#include <linux/zalloc.h>
#include "../../util/cpumap.h"
+#include "../../util/event.h"
#include "../../util/evsel.h"
#include "../../util/evlist.h"
#include "../../util/session.h"
@@ -107,7 +108,7 @@ static int intel_bts_recording_options(struct auxtrace_record *itr,
struct perf_pmu *intel_bts_pmu = btsr->intel_bts_pmu;
struct evsel *evsel, *intel_bts_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
btsr->evlist = evlist;
btsr->snapshot_mode = opts->auxtrace_snapshot_mode;
diff --git a/tools/perf/arch/x86/util/intel-pt.c b/tools/perf/arch/x86/util/intel-pt.c
index 218a4e694618..43d5088ee824 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -558,7 +558,7 @@ static int intel_pt_recording_options(struct auxtrace_record *itr,
bool have_timing_info, need_immediate = false;
struct evsel *evsel, *intel_pt_evsel = NULL;
const struct perf_cpu_map *cpus = evlist->core.cpus;
- bool privileged = geteuid() == 0 || perf_event_paranoid() < 0;
+ bool privileged = perf_event_paranoid_check(-1);
u64 tsc_bit;
int err;
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 64bc32ed6dfa..eafc134bf17c 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -279,7 +279,7 @@ struct evsel *perf_evsel__new_idx(struct perf_event_attr *attr, int idx)
static bool perf_event_can_profile_kernel(void)
{
- return geteuid() == 0 || perf_event_paranoid() == -1;
+ return perf_event_paranoid_check(-1);
}
struct evsel *perf_evsel__new_cycles(bool precise)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/4] perf: Use capabilities instead of uid and euid
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
Series v1: https://lkml.kernel.org/lkml/1562112605-6235-1-git-send-email-ilubashe@akamai.com
Kernel is using capabilities instead of uid and euid to restrict access to
kernel pointers and tracing facilities. This patch series updates the perf to
better match the security model used by the kernel.
This series enables instructions in Documentation/admin-guide/perf-security.rst
to actually work, even when kernel.perf_event_paranoid=2 and
kernel.kptr_restrict=1.
The series consists of four patches:
01: perf: Add capability-related utilities
Add utility functions to check capabilities and perf_event_paranoid checks,
if libcap-dev[el] is available. (Otherwise, assume no capabilities.)
02: perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
Replace the use of euid==0 with a check for CAP_SYS_ADMIN whenever
perf_event_paranoid level is verified.
03: perf: Use CAP_SYSLOG with kptr_restrict checks
Replace the use of uid and euid with a check for CAP_SYSLOG when
kptr_restrict is verified (similar to kernel/kallsyms.c and lib/vsprintf.c).
Consult perf_event_paranoid when kptr_restrict==0 (see kernel/kallsyms.c).
04: perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
Replace the use of euid==0 with a check for CAP_SYS_ADMIN before mounting
debugfs for ftrace.
I tested this by following Documentation/admin-guide/perf-security.rst
guidelines and setting sysctls:
kernel.perf_event_paranoid=2
kernel.kptr_restrict=1
As an unpriviledged user who is in perf_users group (setup via instructions
above), I executed:
perf record -a -- sleep 1
Without the patch, perf record did not capture any kernel functions.
With the patch, perf included all kernel funcitons.
Changelog:
v2: * Added a build feature check for libcap-dev[el] as suggested by Arnaldo
Igor Lubashev (4):
perf: Add capability-related utilities
perf: Use CAP_SYS_ADMIN with perf_event_paranoid checks
perf: Use CAP_SYSLOG with kptr_restrict checks
perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/arch/arm/util/cs-etm.c | 3 ++-
tools/perf/arch/arm64/util/arm-spe.c | 4 ++--
tools/perf/arch/x86/util/intel-bts.c | 3 ++-
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/builtin-ftrace.c | 4 +++-
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/evsel.c | 2 +-
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/symbol.c | 15 +++++++++++----
tools/perf/util/util.c | 9 +++++++++
18 files changed, 127 insertions(+), 11 deletions(-)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 3/4] perf: Use CAP_SYSLOG with kptr_restrict checks
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Kernel is using CAP_SYSLOG capability instead of uid==0 and euid==0 when
checking kptr_restrict. Make perf do the same.
Also, the kernel is a more restrictive than "no restrictions" in case of
kptr_restrict==0, so add the same logic to perf.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/util/symbol.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 173f3378aaa0..046271103499 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -4,6 +4,7 @@
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/mman.h>
#include <linux/time64.h>
@@ -15,8 +16,10 @@
#include <inttypes.h>
#include "annotate.h"
#include "build-id.h"
+#include "cap.h"
#include "util.h"
#include "debug.h"
+#include "event.h"
#include "machine.h"
#include "map.h"
#include "symbol.h"
@@ -890,7 +893,11 @@ bool symbol__restricted_filename(const char *filename,
{
bool restricted = false;
- if (symbol_conf.kptr_restrict) {
+ /* Per kernel/kallsyms.c:
+ * we also restrict when perf_event_paranoid > 1 w/o CAP_SYSLOG
+ */
+ if (symbol_conf.kptr_restrict ||
+ (perf_event_paranoid() > 1 && !perf_cap__capable(CAP_SYSLOG))) {
char *r = realpath(filename, NULL);
if (r != NULL) {
@@ -2190,9 +2197,9 @@ static bool symbol__read_kptr_restrict(void)
char line[8];
if (fgets(line, sizeof(line), fp) != NULL)
- value = ((geteuid() != 0) || (getuid() != 0)) ?
- (atoi(line) != 0) :
- (atoi(line) == 2);
+ value = perf_cap__capable(CAP_SYSLOG) ?
+ (atoi(line) >= 2) :
+ (atoi(line) != 0);
fclose(fp);
}
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/4] perf: Add capability-related utilities
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Add utilities to help checking capabilities of the running procss.
Make perf link with libcap, if it is available. If no libcap-dev[el],
assume no capabilities.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/build/Makefile.feature | 2 ++
tools/build/feature/Makefile | 4 ++++
tools/build/feature/test-libcap.c | 20 ++++++++++++++++++++
tools/perf/Makefile.config | 11 +++++++++++
tools/perf/Makefile.perf | 2 ++
tools/perf/util/Build | 2 ++
tools/perf/util/cap.c | 29 +++++++++++++++++++++++++++++
tools/perf/util/cap.h | 24 ++++++++++++++++++++++++
tools/perf/util/event.h | 1 +
tools/perf/util/python-ext-sources | 1 +
tools/perf/util/util.c | 9 +++++++++
11 files changed, 105 insertions(+)
create mode 100644 tools/build/feature/test-libcap.c
create mode 100644 tools/perf/util/cap.c
create mode 100644 tools/perf/util/cap.h
diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 86b793dffbc4..8a19753cc26a 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -42,6 +42,7 @@ FEATURE_TESTS_BASIC := \
gtk2-infobar \
libaudit \
libbfd \
+ libcap \
libelf \
libelf-getphdrnum \
libelf-gelf_getnote \
@@ -110,6 +111,7 @@ FEATURE_DISPLAY ?= \
gtk2 \
libaudit \
libbfd \
+ libcap \
libelf \
libnuma \
numa_num_possible_cpus \
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 0658b8cd0e53..8499385365c0 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -20,6 +20,7 @@ FILES= \
test-libbfd-liberty.bin \
test-libbfd-liberty-z.bin \
test-cplus-demangle.bin \
+ test-libcap.bin \
test-libelf.bin \
test-libelf-getphdrnum.bin \
test-libelf-gelf_getnote.bin \
@@ -105,6 +106,9 @@ $(OUTPUT)test-fortify-source.bin:
$(OUTPUT)test-bionic.bin:
$(BUILD)
+$(OUTPUT)test-libcap.bin:
+ $(BUILD) -lcap
+
$(OUTPUT)test-libelf.bin:
$(BUILD) -lelf
diff --git a/tools/build/feature/test-libcap.c b/tools/build/feature/test-libcap.c
new file mode 100644
index 000000000000..d2a2e152195f
--- /dev/null
+++ b/tools/build/feature/test-libcap.c
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <sys/capability.h>
+#include <linux/capability.h>
+
+int main(void)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return 1;
+
+ if (cap_get_flag(caps, CAP_SYS_ADMIN, CAP_EFFECTIVE, &val) != 0)
+ return 1;
+
+ if (cap_free(caps) != 0)
+ return 1;
+
+ return 0;
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index e4988f49ea79..9a06787fedc6 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -824,6 +824,17 @@ ifndef NO_LIBZSTD
endif
endif
+ifndef NO_LIBCAP
+ ifeq ($(feature-libcap), 1)
+ CFLAGS += -DHAVE_LIBCAP_SUPPORT
+ EXTLIBS += -lcap
+ $(call detected,CONFIG_LIBCAP)
+ else
+ msg := $(warning No libcap found, disables capability support, please install libcap-devel/libcap-dev);
+ NO_LIBCAP := 1
+ endif
+endif
+
ifndef NO_BACKTRACE
ifeq ($(feature-backtrace), 1)
CFLAGS += -DHAVE_BACKTRACE_SUPPORT
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 67512a12276b..f9807d8c005b 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -88,6 +88,8 @@ include ../scripts/utilities.mak
#
# Define NO_LIBBPF if you do not want BPF support
#
+# Define NO_LIBCAP if you do not want process capabilities considered by perf
+#
# Define NO_SDT if you do not want to define SDT event in perf tools,
# note that it doesn't disable SDT scanning support.
#
diff --git a/tools/perf/util/Build b/tools/perf/util/Build
index 7abf05131889..7cda749059a9 100644
--- a/tools/perf/util/Build
+++ b/tools/perf/util/Build
@@ -148,6 +148,8 @@ perf-$(CONFIG_ZLIB) += zlib.o
perf-$(CONFIG_LZMA) += lzma.o
perf-$(CONFIG_ZSTD) += zstd.o
+perf-$(CONFIG_LIBCAP) += cap.o
+
perf-y += demangle-java.o
perf-y += demangle-rust.o
diff --git a/tools/perf/util/cap.c b/tools/perf/util/cap.c
new file mode 100644
index 000000000000..c3ba841bbf37
--- /dev/null
+++ b/tools/perf/util/cap.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Capability utilities
+ */
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include "cap.h"
+#include <stdbool.h>
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap)
+{
+ cap_flag_value_t val;
+ cap_t caps = cap_get_proc();
+
+ if (!caps)
+ return false;
+
+ if (cap_get_flag(caps, cap, CAP_EFFECTIVE, &val) != 0)
+ val = CAP_CLEAR;
+
+ if (cap_free(caps) != 0)
+ return false;
+
+ return val == CAP_SET;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
diff --git a/tools/perf/util/cap.h b/tools/perf/util/cap.h
new file mode 100644
index 000000000000..514b1f8992f6
--- /dev/null
+++ b/tools/perf/util/cap.h
@@ -0,0 +1,24 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef __PERF_CAP_H
+#define __PERF_CAP_H
+
+#include <stdbool.h>
+#include <linux/capability.h>
+#include <linux/compiler.h>
+
+#ifdef HAVE_LIBCAP_SUPPORT
+
+#include <sys/capability.h>
+
+bool perf_cap__capable(cap_value_t cap);
+
+#else
+
+static inline bool perf_cap__capable(int cap __maybe_unused)
+{
+ return false;
+}
+
+#endif /* HAVE_LIBCAP_SUPPORT */
+
+#endif /* __PERF_CAP_H */
diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 70841d115349..0e164e8ae28d 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -851,6 +851,7 @@ void cpu_map_data__synthesize(struct cpu_map_data *data, struct perf_cpu_map *m
void event_attr_init(struct perf_event_attr *attr);
int perf_event_paranoid(void);
+bool perf_event_paranoid_check(int max_level);
extern int sysctl_perf_event_max_stack;
extern int sysctl_perf_event_max_contexts_per_stack;
diff --git a/tools/perf/util/python-ext-sources b/tools/perf/util/python-ext-sources
index 235bd9803390..c6dd478956f1 100644
--- a/tools/perf/util/python-ext-sources
+++ b/tools/perf/util/python-ext-sources
@@ -7,6 +7,7 @@
util/python.c
../lib/ctype.c
+util/cap.c
util/evlist.c
util/evsel.c
util/cpumap.c
diff --git a/tools/perf/util/util.c b/tools/perf/util/util.c
index 9c3c97697387..6fd130a5d8f2 100644
--- a/tools/perf/util/util.c
+++ b/tools/perf/util/util.c
@@ -16,10 +16,12 @@
#include <string.h>
#include <errno.h>
#include <limits.h>
+#include <linux/capability.h>
#include <linux/kernel.h>
#include <linux/log2.h>
#include <linux/time64.h>
#include <unistd.h>
+#include "cap.h"
#include "strlist.h"
#include "string2.h"
@@ -403,6 +405,13 @@ int perf_event_paranoid(void)
return value;
}
+
+bool perf_event_paranoid_check(int max_level)
+{
+ return perf_cap__capable(CAP_SYS_ADMIN) ||
+ perf_event_paranoid() <= max_level;
+}
+
static int
fetch_ubuntu_kernel_version(unsigned int *puint)
{
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 4/4] perf: Use CAP_SYS_ADMIN instead of euid==0 with ftrace
From: Igor Lubashev @ 2019-08-07 3:35 UTC (permalink / raw)
To: linux-kernel, Arnaldo Carvalho de Melo, Jiri Olsa,
Alexey Budankov
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra, Igor Lubashev,
James Morris, Alexander Shishkin, Ingo Molnar, Namhyung Kim,
linux-arm-kernel
In-Reply-To: <cover.1565146171.git.ilubashe@akamai.com>
Kernel requires CAP_SYS_ADMIN instead of euid==0 to mount debugfs for ftrace.
Make perf do the same.
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
---
tools/perf/builtin-ftrace.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
index ae1466aa3b26..d09eac8a6d57 100644
--- a/tools/perf/builtin-ftrace.c
+++ b/tools/perf/builtin-ftrace.c
@@ -13,6 +13,7 @@
#include <signal.h>
#include <fcntl.h>
#include <poll.h>
+#include <linux/capability.h>
#include "debug.h"
#include <subcmd/parse-options.h>
@@ -21,6 +22,7 @@
#include "target.h"
#include "cpumap.h"
#include "thread_map.h"
+#include "util/cap.h"
#include "util/config.h"
@@ -281,7 +283,7 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int argc, const char **argv)
.events = POLLIN,
};
- if (geteuid() != 0) {
+ if (!perf_cap__capable(CAP_SYS_ADMIN)) {
pr_err("ftrace only works for root!\n");
return -1;
}
--
2.7.4
_______________________________________________
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: [EXT] Re: [PATCH nvmem 1/1] nvmem: imx: add i.MX8QM platform support
From: Andy Duan @ 2019-08-07 3:50 UTC (permalink / raw)
To: Srinivas Kandagatla, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: gregkh@linuxfoundation.org, festevam@gmail.com,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
linux-kernel@vger.kernel.org
In-Reply-To: <65afeaaf-f703-02f2-a918-90a8bb8f58b6@linaro.org>
From: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Sent: Tuesday, August 6, 2019 6:04 PM
> On 04/07/2019 15:20, fugang.duan@nxp.com wrote:
> > From: Fugang Duan <fugang.duan@nxp.com>
> >
> > i.MX8QM efuse table has some difference with i.MX8QXP platform, so add
> > i.MX8QM platform support.
> >
> > Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
> > ---
> > drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/nvmem/imx-ocotp-scu.c
> > b/drivers/nvmem/imx-ocotp-scu.c index be2f5f0..0d78ab4 100644
> > --- a/drivers/nvmem/imx-ocotp-scu.c
> > +++ b/drivers/nvmem/imx-ocotp-scu.c
> > @@ -16,6 +16,7 @@
> >
> > enum ocotp_devtype {
> > IMX8QXP,
> > + IMX8QM,
> > };
> >
> > struct ocotp_devtype_data {
> > @@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
> > .nregs = 800,
> > };
> >
> > +static struct ocotp_devtype_data imx8qm_data = {
> > + .devtype = IMX8QM,
> > + .nregs = 800,
> > +};
> > +
> > static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
> > u32 *val)
> > {
> > @@ -118,6 +124,7 @@ static struct nvmem_config
> > imx_scu_ocotp_nvmem_config = {
> >
> > static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
> > { .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data
> > },
> > + { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
> > { },
>
> Looks like you forgot to add this new compatible to device tree bindings
> at ./Documentation/devicetree/bindings/nvmem/imx-ocotp.txt or forgot to
> add me to CC.
>
> Please resend the patch with it, I can not apply this as it is.
>
> Thanks,
> srini
There have no separated binding documentation for imx-ocotp-scu.c driver.
It is reasonable to add the new compatible string on below binding file "fsl,scu.txt":
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
>
> > };
> > MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
> >
_______________________________________________
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/3] perf: Add capability-related utilities
From: Lubashev, Igor @ 2019-08-07 3:58 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo, Jiri Olsa
Cc: Mathieu Poirier, Suzuki K Poulose, Peter Zijlstra,
linux-kernel@vger.kernel.org, James Morris, Alexander Shishkin,
Ingo Molnar, Namhyung Kim, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190717234652.GJ3624@kernel.org>
On Wed, July 17 at 2019 7:47 PM Arnaldo Carvalho de Melo wrote:
> Em Wed, Jul 17, 2019 at 06:05:51PM -0300, Arnaldo Carvalho de Melo
> escreveu:
> > Em Tue, Jul 16, 2019 at 10:46:43AM +0200, Jiri Olsa escreveu:
> > > On Tue, Jul 02, 2019 at 08:10:03PM -0400, Igor Lubashev wrote:
> > > > Add utilities to help checking capabilities of the running process.
> > > > Make perf link with libcap.
> > > >
> > > > Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
> > > > ---
> > > > tools/perf/Makefile.config | 2 +-
> > > > tools/perf/util/Build | 1 +
> > > > tools/perf/util/cap.c | 24 ++++++++++++++++++++++++
> > > > tools/perf/util/cap.h | 10 ++++++++++
> > > > tools/perf/util/event.h | 1 +
> > > > tools/perf/util/python-ext-sources | 1 +
> > > > tools/perf/util/util.c | 9 +++++++++
> > > > 7 files changed, 47 insertions(+), 1 deletion(-) create mode
> > > > 100644 tools/perf/util/cap.c create mode 100644
> > > > tools/perf/util/cap.h
> > > >
> > > > diff --git a/tools/perf/Makefile.config
> > > > b/tools/perf/Makefile.config index 85fbcd265351..21470a50ed39
> > > > 100644
> > > > --- a/tools/perf/Makefile.config
> > > > +++ b/tools/perf/Makefile.config
> > > > @@ -259,7 +259,7 @@ CXXFLAGS += -Wno-strict-aliasing # adding
> > > > assembler files missing the .GNU-stack linker note.
> > > > LDFLAGS += -Wl,-z,noexecstack
> > > >
> > > > -EXTLIBS = -lpthread -lrt -lm -ldl
> > > > +EXTLIBS = -lpthread -lrt -lm -ldl -lcap
> > >
> > > I wonder we should detect libcap or it's everywhere.. Arnaldo's
> > > compile test suite might tell
> >
> > I'll add this tentatively and try to build it in my test suite.
>
> So, not even in my notebook this worked straight away:
>
> CC /tmp/build/perf/util/cap.o
> CC /tmp/build/perf/util/config.o
> In file included from util/cap.c:5:
> util/cap.h:6:10: fatal error: sys/capability.h: No such file or directory
> 6 | #include <sys/capability.h>
> | ^~~~~~~~~~~~~~~~~~
> compilation terminated.
> mv: cannot stat '/tmp/build/perf/util/.cap.o.tmp': No such file or directory
>
>
> I had to first do:
>
> dnf install libcap-devel
>
> So we need to have a feature test and fail if that is not installed, i.e. libcap
> becomes a hard req for building perf, which I think is reasonable, one more
> shouldn't hurt, right?
>
> With all the features enabled:
>
> [acme@quaco perf]$ ldd ~/bin/perf
> linux-vdso.so.1 (0x00007ffe7278a000)
> libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8
> (0x00007f7be52f1000)
> libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f7be52d7000)
> liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f7be52ae000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f7be528d000)
> librt.so.1 => /lib64/librt.so.1 (0x00007f7be5283000)
> libm.so.6 => /lib64/libm.so.6 (0x00007f7be513d000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f7be5135000)
> libcap.so.2 => /lib64/libcap.so.2 (0x00007f7be512e000)
> libelf.so.1 => /lib64/libelf.so.1 (0x00007f7be5113000)
> libdw.so.1 => /lib64/libdw.so.1 (0x00007f7be50c0000)
> libslang.so.2 => /lib64/libslang.so.2 (0x00007f7be4de8000)
> libperl.so.5.28 => /lib64/libperl.so.5.28 (0x00007f7be4ac2000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f7be48fa000)
> libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0
> (0x00007f7be4690000)
> libz.so.1 => /lib64/libz.so.1 (0x00007f7be4676000)
> libzstd.so.1 => /lib64/libzstd.so.1 (0x00007f7be45d1000)
> libnuma.so.1 => /lib64/libnuma.so.1 (0x00007f7be45c3000)
> libbabeltrace-ctf.so.1 => /lib64/libbabeltrace-ctf.so.1
> (0x00007f7be456d000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f7be4551000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f7be5331000)
> libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f7be453d000)
> libcrypt.so.2 => /lib64/libcrypt.so.2 (0x00007f7be4502000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00007f7be44fd000)
> libbabeltrace.so.1 => /lib64/libbabeltrace.so.1
> (0x00007f7be44ed000)
> libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f7be44dd000)
> libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f7be44d3000)
> libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0
> (0x00007f7be44cd000)
> libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f7be43a9000)
> libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f7be4335000)
> [acme@quaco perf]$
>
> ;-)
>
> So, please check tools/build/feature/ and check how this is done and add a
> test and the warning in tools/perf/Makefile.config so that we get an error
> message stating that libcap-dev or libcap-devel should be installed.
I have just posted v2 of the series (https://lkml.kernel.org/lkml/cover.1565146171.git.ilubashe@akamai.com).
Instead of making libcap is "hard req", I made it as "soft" one. We can still build a useful tool w/o libcap. It will just have to assume that perf is running with no capabilities, since we cannot query them.
Many thanks for the pointers on how to go about build feature checking.
- Igor
_______________________________________________
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] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Alex Deucher @ 2019-08-07 4:02 UTC (permalink / raw)
To: Jisheng Zhang
Cc: kernel-build-reports@lists.linaro.org, broonie@kernel.org,
Tao Zhou, amd-gfx@lists.freedesktop.org,
linux-next@vger.kernel.org, dennis.li@amd.com,
alexander.deucher@amd.com, akpm@linux-foundation.org,
christian.koenig@amd.com, linux-arm-kernel@lists.infradead.org,
hawking.zhang@amd.com
In-Reply-To: <20190807105759.58a28ef0@xhacker.debian>
On Tue, Aug 6, 2019 at 11:31 PM Jisheng Zhang
<Jisheng.Zhang@synaptics.com> wrote:
>
> On Wed, 7 Aug 2019 10:56:40 +0800 Tao Zhou wrote:
>
>
> >
> >
> > readq/writeq are not supported on all architectures
> >
> > Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> > 1 file changed, 2 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > index 558fe6d091ed..7eb9e0b9235a 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> > @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> > */
> > uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> > {
> > - uint64_t ret;
> > -
> > if ((reg * 4) < adev->rmmio_size)
> > - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> > + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
>
> atomic64_read doesn't equal to readq on some architectures..
What we really wanted originally was atomic64. We basically want a
read or write that is guaranteed to be 64 bits at a time.
Alex
>
> > else
> > BUG();
> > -
> > - return ret;
> > }
> >
> > /**
> > @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> > void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> > {
> > if ((reg * 4) < adev->rmmio_size)
> > - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> > + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> > else
> > BUG();
> > }
> > --
> > 2.17.1
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
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] drm/amdgpu: replace readq/writeq with atomic64 operations
From: Alex Deucher @ 2019-08-07 4:03 UTC (permalink / raw)
To: Tao Zhou
Cc: linux-arm-kernel, kernel-build-reports, amd-gfx list, Mark Brown,
Linux-Next Mailing List, Deucher, Alexander, Andrew Morton,
Christian Koenig, Dennis Li, Hawking Zhang
In-Reply-To: <20190807025640.682-1-tao.zhou1@amd.com>
On Tue, Aug 6, 2019 at 10:56 PM Tao Zhou <tao.zhou1@amd.com> wrote:
>
> readq/writeq are not supported on all architectures
>
> Signed-off-by: Tao Zhou <tao.zhou1@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 558fe6d091ed..7eb9e0b9235a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -272,14 +272,10 @@ void amdgpu_mm_wreg(struct amdgpu_device *adev, uint32_t reg, uint32_t v,
> */
> uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> {
> - uint64_t ret;
> -
> if ((reg * 4) < adev->rmmio_size)
> - ret = readq(((void __iomem *)adev->rmmio) + (reg * 4));
> + return atomic64_read((atomic64_t *)(adev->rmmio + (reg * 4)));
> else
> BUG();
> -
> - return ret;
> }
>
> /**
> @@ -294,7 +290,7 @@ uint64_t amdgpu_mm_rreg64(struct amdgpu_device *adev, uint32_t reg)
> void amdgpu_mm_wreg64(struct amdgpu_device *adev, uint32_t reg, uint64_t v)
> {
> if ((reg * 4) < adev->rmmio_size)
> - writeq(v, ((void __iomem *)adev->rmmio) + (reg * 4));
> + atomic64_set((atomic64_t *)(adev->rmmio + (reg * 4)), v);
> else
> BUG();
> }
> --
> 2.17.1
>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 1/1] i2c: iproc: Add i2c repeated start capability
From: Rayagonda Kokatanur @ 2019-08-07 4:09 UTC (permalink / raw)
To: Wolfram Sang, Rob Herring, Mark Rutland
Cc: devicetree, Lori Hikichi, Florian Fainelli, Shivaraj Shetty,
Rayagonda Kokatanur, linux-kernel, Icarus Chau, Ray Jui,
linux-i2c, bcm-kernel-feedback-list, linux-arm-kernel
From: Lori Hikichi <lori.hikichi@broadcom.com>
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi <lori.hikichi@broadcom.com>
Signed-off-by: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
Signed-off-by: Icarus Chau <icarus.chau@broadcom.com>
Signed-off-by: Ray Jui <ray.jui@broadcom.com>
Signed-off-by: Shivaraj Shetty <sshetty1@broadcom.com>
---
drivers/i2c/busses/i2c-bcm-iproc.c | 70 +++++++++++++++++++++++++++++++-------
1 file changed, 57 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..15fedcf 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR 0x7
#define M_CMD_PROTOCOL_BLK_RD 0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK 0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
- struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = &msgs[0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+ * The last byte to be sent out should be a slave
+ * address with read operation
+ */
+ addr = msg->addr << 1 | 1;
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(&iproc_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK_WR << M_CMD_PROTOCOL_SHIFT);
@@ -774,17 +802,31 @@ static int bcm_iproc_i2c_xfer(struct i2c_adapter *adapter,
struct i2c_msg msgs[], int num)
{
struct bcm_iproc_i2c_dev *iproc_i2c = i2c_get_adapdata(adapter);
- int ret, i;
+ bool process_call = false;
+ int ret;
- /* go through all messages */
- for (i = 0; i < num; i++) {
- ret = bcm_iproc_i2c_xfer_single_msg(iproc_i2c, &msgs[i]);
- if (ret) {
- dev_dbg(iproc_i2c->device, "xfer failed\n");
- return ret;
+ if (num > 2) {
+ dev_err(iproc_i2c->device,
+ "Only support up to 2 messages. Current msg count %d\n",
+ num);
+ return -EOPNOTSUPP;
+ }
+
+ if (num == 2) {
+ /* Repeated start, use process call */
+ process_call = true;
+ if (msgs[1].flags & I2C_M_NOSTART) {
+ dev_err(iproc_i2c->device, "Invalid repeated start\n");
+ return -EOPNOTSUPP;
}
}
+ ret = bcm_iproc_i2c_xfer_internal(iproc_i2c, msgs, process_call);
+ if (ret) {
+ dev_dbg(iproc_i2c->device, "xfer failed\n");
+ return ret;
+ }
+
return num;
}
@@ -806,6 +848,8 @@ static uint32_t bcm_iproc_i2c_functionality(struct i2c_adapter *adap)
};
static struct i2c_adapter_quirks bcm_iproc_i2c_quirks = {
+ .flags = I2C_AQ_COMB_WRITE_THEN_READ,
+ .max_comb_1st_msg_len = M_TX_RX_FIFO_SIZE,
.max_read_len = M_RX_MAX_READ_LEN,
};
--
1.9.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
* [PATCH nvmem v2 0/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
From: Fugang Duan <fugang.duan@nxp.com>
The patch set is to add i.MX8QM platform support for i.MX8 SCU
OCOTP driver due to i.MX8QM efuse table has some difference with
i.MX8QXP platform.
V2:
- Add dt-bindings for the new compatible string support.
Fugang Duan (2):
nvmem: imx: add i.MX8QM platform support
dt-bindings: fsl: scu: add new compatible string for ocotp
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH nvmem v2 1/2] nvmem: imx: add i.MX8QM platform support
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
i.MX8QM efuse table has some difference with i.MX8QXP platform,
so add i.MX8QM platform support.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
drivers/nvmem/imx-ocotp-scu.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/nvmem/imx-ocotp-scu.c b/drivers/nvmem/imx-ocotp-scu.c
index be2f5f0..0d78ab4 100644
--- a/drivers/nvmem/imx-ocotp-scu.c
+++ b/drivers/nvmem/imx-ocotp-scu.c
@@ -16,6 +16,7 @@
enum ocotp_devtype {
IMX8QXP,
+ IMX8QM,
};
struct ocotp_devtype_data {
@@ -39,6 +40,11 @@ static struct ocotp_devtype_data imx8qxp_data = {
.nregs = 800,
};
+static struct ocotp_devtype_data imx8qm_data = {
+ .devtype = IMX8QM,
+ .nregs = 800,
+};
+
static int imx_sc_misc_otp_fuse_read(struct imx_sc_ipc *ipc, u32 word,
u32 *val)
{
@@ -118,6 +124,7 @@ static struct nvmem_config imx_scu_ocotp_nvmem_config = {
static const struct of_device_id imx_scu_ocotp_dt_ids[] = {
{ .compatible = "fsl,imx8qxp-scu-ocotp", (void *)&imx8qxp_data },
+ { .compatible = "fsl,imx8qm-scu-ocotp", (void *)&imx8qm_data },
{ },
};
MODULE_DEVICE_TABLE(of, imx_scu_ocotp_dt_ids);
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH nvmem v2 2/2] dt-bindings: fsl: scu: add new compatible string for ocotp
From: fugang.duan @ 2019-08-07 4:03 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: mark.rutland, robh, festevam, fugang.duan, devicetree, gregkh,
s.hauer, linux-kernel, kernel, shawnguo, linux-arm-kernel
In-Reply-To: <20190807040320.1760-1-fugang.duan@nxp.com>
From: Fugang Duan <fugang.duan@nxp.com>
Add new compatible string "fsl,imx8qm-scu-ocotp" into binding
doc for i.MX8 SCU OCOTP driver.
Signed-off-by: Fugang Duan <fugang.duan@nxp.com>
---
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
index a575e42..c149fad 100644
--- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
@@ -136,7 +136,9 @@ Required properties:
OCOTP bindings based on SCU Message Protocol
------------------------------------------------------------
Required properties:
-- compatible: Should be "fsl,imx8qxp-scu-ocotp"
+- compatible: Should be one of:
+ "fsl,imx8qm-scu-ocotp",
+ "fsl,imx8qxp-scu-ocotp".
- #address-cells: Must be 1. Contains byte index
- #size-cells: Must be 1. Contains byte length
--
2.7.4
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] arm64: mm: add missing PTE_SPECIAL in pte_mkdevmap on arm64
From: Jia He @ 2019-08-07 4:58 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, Mark Rutland, James Morse
Cc: Jia He, Anshuman Khandual, Christoffer Dall, linux-kernel,
Jun Yao, Qian Cai, Punit Agrawal, Thomas Gleixner, Robin Murphy,
Alex Van Brunt, linux-arm-kernel
Without this patch, the MAP_SYNC test case will cause a print_bad_pte
warning on arm64 as follows:
[ 25.542693] BUG: Bad page map in process mapdax333
pte:2e8000448800f53 pmd:41ff5f003
[ 25.546360] page:ffff7e0010220000 refcount:1 mapcount:-1
mapping:ffff8003e29c7440 index:0x0
[ 25.550281] ext4_dax_aops
[ 25.550282] name:"__aaabbbcccddd__"
[ 25.551553] flags: 0x3ffff0000001002(referenced|reserved)
[ 25.555802] raw: 03ffff0000001002 ffff8003dfffa908 0000000000000000
ffff8003e29c7440
[ 25.559446] raw: 0000000000000000 0000000000000000 00000001fffffffe
0000000000000000
[ 25.563075] page dumped because: bad pte
[ 25.564938] addr:0000ffffbe05b000 vm_flags:208000fb
anon_vma:0000000000000000 mapping:ffff8003e29c7440 index:0
[ 25.574272] file:__aaabbbcccddd__ fault:ext4_dax_fault
mmmmap:ext4_file_mmap readpage:0x0
[ 25.578799] CPU: 1 PID: 1180 Comm: mapdax333 Not tainted 5.2.0+ #21
[ 25.581702] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.585624] Call trace:
[ 25.587008] dump_backtrace+0x0/0x178
[ 25.588799] show_stack+0x24/0x30
[ 25.590328] dump_stack+0xa8/0xcc
[ 25.591901] print_bad_pte+0x18c/0x218
[ 25.593628] unmap_page_range+0x778/0xc00
[ 25.595506] unmap_single_vma+0x94/0xe8
[ 25.597304] unmap_vmas+0x90/0x108
[ 25.598901] unmap_region+0xc0/0x128
[ 25.600566] __do_munmap+0x284/0x3f0
[ 25.602245] __vm_munmap+0x78/0xe0
[ 25.603820] __arm64_sys_munmap+0x34/0x48
[ 25.605709] el0_svc_common.constprop.0+0x78/0x168
[ 25.607956] el0_svc_handler+0x34/0x90
[ 25.609698] el0_svc+0x8/0xc
[ 25.611103] Disabling lock debugging due to kernel taint
[ 25.613573] BUG: Bad page state in process mapdax333 pfn:448800
[ 25.616359] page:ffff7e0010220000 refcount:0 mapcount:-1
mapping:ffff8003e29c7440 index:0x1
[ 25.620236] ext4_dax_aops
[ 25.620237] name:"__aaabbbcccddd__"
[ 25.621495] flags: 0x3ffff0000000000()
[ 25.624912] raw: 03ffff0000000000 dead000000000100 dead000000000200
ffff8003e29c7440
[ 25.628502] raw: 0000000000000001 0000000000000000 00000000fffffffe
0000000000000000
[ 25.632097] page dumped because: non-NULL mapping
[...]
[ 25.656567] CPU: 1 PID: 1180 Comm: mapdax333 Tainted: G B
5.2.0+ #21
[ 25.660131] Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0
02/06/2015
[ 25.663324] Call trace:
[ 25.664466] dump_backtrace+0x0/0x178
[ 25.666163] show_stack+0x24/0x30
[ 25.667721] dump_stack+0xa8/0xcc
[ 25.669270] bad_page+0xf0/0x150
[ 25.670772] free_pages_check_bad+0x84/0xa0
[ 25.672724] free_pcppages_bulk+0x45c/0x708
[ 25.674675] free_unref_page_commit+0xcc/0x100
[ 25.676751] free_unref_page_list+0x13c/0x200
[ 25.678801] release_pages+0x350/0x420
[ 25.680539] free_pages_and_swap_cache+0xf8/0x128
[ 25.682738] tlb_flush_mmu+0x164/0x2b0
[ 25.684485] unmap_page_range+0x648/0xc00
[ 25.686349] unmap_single_vma+0x94/0xe8
[ 25.688131] unmap_vmas+0x90/0x108
[ 25.689739] unmap_region+0xc0/0x128
[ 25.691392] __do_munmap+0x284/0x3f0
[ 25.693079] __vm_munmap+0x78/0xe0
[ 25.694658] __arm64_sys_munmap+0x34/0x48
[ 25.696530] el0_svc_common.constprop.0+0x78/0x168
[ 25.698772] el0_svc_handler+0x34/0x90
[ 25.700512] el0_svc+0x8/0xc
The root cause is in _vm_normal_page, without the PTE_SPECIAL bit,
the return value will be incorrectly set to pfn_to_page(pfn) instead
of NULL. Besides, this patch also rewrite the pmd_mkdevmap to avoid
setting PTE_SPECIAL for pmd
The MAP_SYNC test case is as follows(Provided by Yibo Cai)
$#include <stdio.h>
$#include <string.h>
$#include <unistd.h>
$#include <sys/file.h>
$#include <sys/mman.h>
$#ifndef MAP_SYNC
$#define MAP_SYNC 0x80000
$#endif
/* mount -o dax /dev/pmem0 /mnt */
$#define F "/mnt/__aaabbbcccddd__"
int main(void)
{
int fd;
char buf[4096];
void *addr;
if ((fd = open(F, O_CREAT|O_TRUNC|O_RDWR, 0644)) < 0) {
perror("open1");
return 1;
}
if (write(fd, buf, 4096) != 4096) {
perror("lseek");
return 1;
}
addr = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_SYNC,
fd, 0);
if (addr == MAP_FAILED) {
perror("mmap");
printf("did you mount with '-o dax'?\n");
return 1;
}
memset(addr, 0x55, 4096);
if (munmap(addr, 4096) == -1) {
perror("munmap");
return 1;
}
close(fd);
return 0;
}
Fixes: 73b20c84d42d ("arm64: mm: implement pte_devmap support")
Reported-by: Yibo Cai <Yibo.Cai@arm.com>
Signed-off-by: Jia He <justin.he@arm.com>
Acked-by: Robin Murphy <Robin.Murphy@arm.com>
---
arch/arm64/include/asm/pgtable.h | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 5fdcfe237338..e09760ece844 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -209,7 +209,7 @@ static inline pmd_t pmd_mkcont(pmd_t pmd)
static inline pte_t pte_mkdevmap(pte_t pte)
{
- return set_pte_bit(pte, __pgprot(PTE_DEVMAP));
+ return set_pte_bit(pte, __pgprot(PTE_DEVMAP | PTE_SPECIAL));
}
static inline void set_pte(pte_t *ptep, pte_t pte)
@@ -396,7 +396,10 @@ static inline int pmd_protnone(pmd_t pmd)
#ifdef CONFIG_TRANSPARENT_HUGEPAGE
#define pmd_devmap(pmd) pte_devmap(pmd_pte(pmd))
#endif
-#define pmd_mkdevmap(pmd) pte_pmd(pte_mkdevmap(pmd_pte(pmd)))
+static inline pmd_t pmd_mkdevmap(pmd_t pmd)
+{
+ return pte_pmd(set_pte_bit(pmd_pte(pmd), __pgprot(PTE_DEVMAP)));
+}
#define __pmd_to_phys(pmd) __pte_to_phys(pmd_pte(pmd))
#define __phys_to_pmd_val(phys) __phys_to_pte_val(phys)
--
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: [PATCH v2] net: mdio-octeon: Fix Kconfig warnings and build errors
From: Nathan Chancellor @ 2019-08-07 5:10 UTC (permalink / raw)
To: David Miller
Cc: devel, andrew, f.fainelli, lkp, kernel-build-reports, gregkh,
rdunlap, willy, broonie, linux-next, netdev, linux-arm-kernel,
hkallweit1
In-Reply-To: <20190806.141133.1365654857955536268.davem@davemloft.net>
On Tue, Aug 06, 2019 at 02:11:33PM -0700, David Miller wrote:
> From: Nathan Chancellor <natechancellor@gmail.com>
> Date: Fri, 2 Aug 2019 23:01:56 -0700
>
> > After commit 171a9bae68c7 ("staging/octeon: Allow test build on
> > !MIPS"), the following combination of configs cause a few Kconfig
> > warnings and build errors (distilled from arm allyesconfig and Randy's
> > randconfig builds):
> >
> > CONFIG_NETDEVICES=y
> > CONFIG_STAGING=y
> > CONFIG_COMPILE_TEST=y
> >
> > and CONFIG_OCTEON_ETHERNET as either a module or built-in.
> >
> > WARNING: unmet direct dependencies detected for MDIO_OCTEON
> > Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
> > && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
> > Selected by [y]:
> > - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
> > COMPILE_TEST [=y]) && NETDEVICES [=y]
> >
> > In file included from ../drivers/net/phy/mdio-octeon.c:14:
> > ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
> > function ‘writeq’; did you mean ‘writel’?
> > [-Werror=implicit-function-declaration]
> > 111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
> > | ^~~~~~
> >
> > CONFIG_64BIT is not strictly necessary if the proper readq/writeq
> > definitions are included from io-64-nonatomic-lo-hi.h.
> >
> > CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
> > of commit f9dc9ac51610 ("of/mdio: Add dummy functions in of_mdio.h.").
> >
> > Fixes: 171a9bae68c7 ("staging/octeon: Allow test build on !MIPS")
> > Reported-by: kbuild test robot <lkp@intel.com>
> > Reported-by: Mark Brown <broonie@kernel.org>
> > Reported-by: Randy Dunlap <rdunlap@infradead.org>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
>
> Applied to net-next.
>
> Please make it clear what tree your changes are targetting in the future,
> thank you.
Sorry for the confusion, I'll do my best to add a patch suffix in the
future.
Thank you for picking this up!
Nathan
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v5 3/4] drm/mediatek: add mt8183 dpi clock factor
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
In-Reply-To: <20190807060257.57007-1-jitao.shi@mediatek.com>
The factor depends on the divider of DPI in MT8183, therefore,
we should fix this factor to the right and new one.
Signed-off-by: Jitao Shi <jitao.shi@mediatek.com>
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 743230864ba0..4f2700cbfdb7 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -672,6 +672,16 @@ static unsigned int mt2701_calculate_factor(int clock)
return 1;
}
+static unsigned int mt8183_calculate_factor(int clock)
+{
+ if (clock <= 27000)
+ return 8;
+ else if (clock <= 167000)
+ return 4;
+ else
+ return 2;
+}
+
static const struct mtk_dpi_conf mt8173_conf = {
.cal_factor = mt8173_calculate_factor,
.reg_h_fre_con = 0xe0,
@@ -683,6 +693,11 @@ static const struct mtk_dpi_conf mt2701_conf = {
.edge_sel_en = true,
};
+static const struct mtk_dpi_conf mt8183_conf = {
+ .cal_factor = mt8183_calculate_factor,
+ .reg_h_fre_con = 0xe0,
+};
+
static int mtk_dpi_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -779,6 +794,9 @@ static const struct of_device_id mtk_dpi_of_ids[] = {
{ .compatible = "mediatek,mt8173-dpi",
.data = &mt8173_conf,
},
+ { .compatible = "mediatek,mt8183-dpi",
+ .data = &mt8183_conf,
+ },
{ },
};
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v5 0/4] add mt8183 dpi driver
From: Jitao Shi @ 2019-08-07 6:02 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, linux-pwm,
David Airlie, Matthias Brugger
Cc: stonea168, dri-devel, Andy Yan, Ajay Kumar, Vincent Palatin,
cawa.cheng, bibby.hsieh, ck.hu, Russell King, Thierry Reding,
devicetree, Jitao Shi, Philipp Zabel, Inki Dae, linux-mediatek,
yingjoe.chen, eddie.huang, linux-arm-kernel, Rahul Sharma,
srv_heupstream, linux-kernel, Sascha Hauer, Sean Paul
Changes since v4:
- move pin mode control and dual edge control to deveice tree.
- update dt-bindings document for pin mode swap and dual edge control.
Changes since v3:
- add dpi pin mode control when dpi on or off.
- update dpi dual edge comment.
Changes since v2:
- update dt-bindings document for mt8183 dpi.
- separate dual edge modfication as independent patch.
Jitao Shi (4):
dt-bindings: display: mediatek: update dpi supported chips
drm/mediatek: dpi dual edge support
drm/mediatek: add mt8183 dpi clock factor
drm/mediatek: control dpi pins dpi or gpio mode in on or off
.../display/mediatek/mediatek,dpi.txt | 11 +++
drivers/gpu/drm/mediatek/mtk_dpi.c | 71 ++++++++++++++++++-
2 files changed, 80 insertions(+), 2 deletions(-)
--
2.21.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
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