* Re: [PATCH 03/11] clocksource: sun4i: Add missing compatibles
From: Daniel Lezcano @ 2019-08-19 13:45 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Rob Herring, tglx,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20190819133058.bujcawpw5rgsfp4g@flea>
[-- Attachment #1.1.1: Type: text/plain, Size: 1109 bytes --]
On 19/08/2019 15:30, Maxime Ripard wrote:
> On Mon, Aug 12, 2019 at 01:24:11PM +0200, Maxime Ripard wrote:
>> On Mon, Aug 12, 2019 at 11:21:50AM +0200, Daniel Lezcano wrote:
>>> On 12/08/2019 11:16, Maxime Ripard wrote:
>>>> Hi,
>>>>
>>>> On Mon, Aug 12, 2019 at 10:59:51AM +0200, Daniel Lezcano wrote:
>>>>> On 22/07/2019 10:12, Maxime Ripard wrote:
>>>>>> Newer Allwinner SoCs have different number of interrupts, let's add
>>>>>> different compatibles for all of them to deal with this properly.
>>>>>>
>>>>>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
>>>>>
>>>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>>
>>>> Thanks!
>>>>
>>>> Can you merge this through your tree (along with the bindings)? I'll
>>>> merge the DT patches
>>>
>>> patches 1-4 then ?
>>
>> Yep, thanks!
>
> Ping?
They are applied :)
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 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 0/2] Introduce Tanix TX6 box DT
From: Maxime Ripard @ 2019-08-19 13:44 UTC (permalink / raw)
To: Jernej Skrabec
Cc: mark.rutland, devicetree, linux-kernel, wens, robh+dt,
linux-arm-kernel
In-Reply-To: <20190816205342.29552-1-jernej.skrabec@siol.net>
[-- Attachment #1.1: Type: text/plain, Size: 592 bytes --]
On Fri, Aug 16, 2019 at 10:53:40PM +0200, Jernej Skrabec wrote:
> This series adds support for Tanix TX6 box:
> - Allwinner H6 Quad-core 64-bit ARM Cortex-A53
> - GPU Mali-T720
> - 4GiB DDR3 RAM (3GiB useable)
> - 100Mbps EMAC via AC200 EPHY
> - Cdtech 47822BS Wifi/BT
> - 2x USB 2.0 Host and 1x USB 3.0 Host
> - HDMI port
> - IR receiver
> - 64GiB eMMC
> - 5V/2A DC power supply
>
> Patch 1 adds compatible strings to dt bindings documentation.
>
> Patch 2 adds Tanix TX6 DT.
Applied both, thanks
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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 v3 4/5] arm64: dts: imx8qxp: Add DSP DT node
From: Shawn Guo @ 2019-08-19 13:44 UTC (permalink / raw)
To: Daniel Baluta
Cc: aisheng.dong, devicetree, peng.fan, anson.huang, shengjiu.wang,
linux-kernel, m.felsch, paul.olaru, robh+dt, linux-imx, kernel,
l.stach, pierre-louis.bossart, mark.rutland, leonard.crestez,
festevam, linux-arm-kernel, sound-open-firmware
In-Reply-To: <20190807164258.8306-5-daniel.baluta@nxp.com>
On Wed, Aug 07, 2019 at 07:42:57PM +0300, Daniel Baluta wrote:
> This includes DSP reserved memory, ADMA DSP device and DSP MU
> communication channels description.
>
> Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Applied, thanks.
_______________________________________________
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] scsi: ufs: fix broken hba->outstanding_tasks
From: Stanley Chu @ 2019-08-19 13:43 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar,
pedrom.sousa
Cc: marc.w.gonzalez, andy.teng, chun-hung.wu, kuohong.wang, evgreen,
linux-mediatek, peter.wang, matthias.bgg, Stanley Chu,
linux-arm-kernel, beanhuo
Currently bits in hba->outstanding_tasks are cleared only after their
corresponding task management commands are successfully done by
__ufshcd_issue_tm_cmd().
If timeout happens in a task management command, its corresponding
bit in hba->outstanding_tasks will not be cleared until next task
management command with the same tag used successfully finishes.
This is wrong and can lead to some issues, like power issue.
For example, ufshcd_release() and ufshcd_gate_work() will do nothing
if hba->outstanding_tasks is not zero even if both UFS host and devices
are actually idle.
Solution is referried from error handling of device commands: bits in
hba->outstanding_tasks shall be cleared regardless of their execution
results.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
---
drivers/scsi/ufs/ufshcd.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index 3804a704e565..30b752c61b97 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -5676,13 +5676,12 @@ static int __ufshcd_issue_tm_cmd(struct ufs_hba *hba,
memcpy(treq, hba->utmrdl_base_addr + free_slot, sizeof(*treq));
ufshcd_add_tm_upiu_trace(hba, task_tag, "tm_complete");
-
- spin_lock_irqsave(hba->host->host_lock, flags);
- __clear_bit(free_slot, &hba->outstanding_tasks);
- spin_unlock_irqrestore(hba->host->host_lock, flags);
-
}
+ spin_lock_irqsave(hba->host->host_lock, flags);
+ __clear_bit(free_slot, &hba->outstanding_tasks);
+ spin_unlock_irqrestore(hba->host->host_lock, flags);
+
clear_bit(free_slot, &hba->tm_condition);
ufshcd_put_tm_slot(hba, free_slot);
wake_up(&hba->tm_tag_wq);
--
2.18.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
* Re: [PATCH RESEND V2 7/7] arm64: dts: imx8mn: Add cpu-freq support
From: Shawn Guo @ 2019-08-19 13:40 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd,
viresh.kumar, s.hauer, rjw, linux-kernel, linux-clk, robh+dt,
Linux-imx, kernel, leonard.crestez, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1566109945-11149-7-git-send-email-Anson.Huang@nxp.com>
On Sun, Aug 18, 2019 at 02:32:25AM -0400, Anson Huang wrote:
> Add A53 OPP table, cpu regulator and speed grading node to
> support cpu-freq driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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 0/9] Exynos Adaptive Supply Voltage support
From: Sylwester Nawrocki @ 2019-08-19 13:39 UTC (permalink / raw)
To: Viresh Kumar
Cc: devicetree, linux-samsung-soc, linux-pm, vireshk, b.zolnierkie,
linux-kernel, krzk, robh+dt, kgene, pankaj.dubey,
linux-arm-kernel, Marek Szyprowski
In-Reply-To: <20190819112533.bvfyinw7fsebkufr@vireshk-i7>
On 8/19/19 13:25, Viresh Kumar wrote:
> On 19-08-19, 13:16, Sylwester Nawrocki wrote:
>> On 8/19/19 11:09, Viresh Kumar wrote:
>>> Will something like this help ?
>>>
>>> https://lore.kernel.org/lkml/1442623929-4507-3-git-send-email-sboyd@codeaurora.org/
>>>
>>> This never got merged but the idea was AVS only.
>>
>> It's quite interesting work, it seems to be for a more advanced use case
>> where OPP voltage is being adjusted at runtime.
>>
>> We could use it instead of removing an OPP and then adding with updated
>> voltage. On Exynos there is there is just a need to update OPPs once at boot
>> time, so it is more "static". However the requirements could presumably
>> change in future.
>
> The API is about changing the values after they are parsed once from DT. You can
> change it once or multiple times depending on the use case.
>
>> If that's your preference I could switch to that notifier approach.
>
> You shouldn't be required to use the notifier. Just add the OPP table and update
> the values right after that. So no one would be using the values at that time.
OK, now I see dev_pm_opp_adjust_voltage() actually changes OPP's voltage
and the notifier is optional.
> Will this patchset solve the problems for you and make your DT light weight ?
Unfortunately not, the patch set as I see it is another way of updating
an OPP after it was parsed from DT. OPP remove/add could work equally
well in our use case.
The problem is that we have the information on how to translate the
common OPP voltage to a voltage specific to given silicon encoded jointly
in the ASV tables and the CHIPID registers (efuse/OTP memory).
Additionally, algorithm of selecting ASV data (OPP voltage) based on
the "key" data from registers is not generic, it is usually different
per each SoC type.
I tried to identify some patterns in those tables in order to simplify
possible DT binding, but that was not really successful. I ended up just
keeping whole tables.
--
Regards,
Sylwester
_______________________________________________
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 RESEND V2 6/7] clk: imx8mn: Add necessary frequency support for ARM PLL table
From: Shawn Guo @ 2019-08-19 13:39 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd,
viresh.kumar, s.hauer, rjw, linux-kernel, linux-clk, robh+dt,
Linux-imx, kernel, leonard.crestez, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1566109945-11149-6-git-send-email-Anson.Huang@nxp.com>
On Sun, Aug 18, 2019 at 02:32:24AM -0400, Anson Huang wrote:
> i.MX8MN supports CPU running at 1.5GHz/1.4GHz/1.2GHz, add missing
> frequency for ARM PLL table.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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 0/3] scsi: ufs: fix broken hba->outstanding_tasks
From: Stanley Chu @ 2019-08-19 13:38 UTC (permalink / raw)
To: Avri Altman
Cc: linux-scsi@vger.kernel.org, martin.petersen@oracle.com,
marc.w.gonzalez@free.fr, andy.teng@mediatek.com,
chun-hung.wu@mediatek.com, kuohong.wang@mediatek.com,
evgreen@chromium.org, linux-mediatek@lists.infradead.org,
peter.wang@mediatek.com, alim.akhtar@samsung.com,
matthias.bgg@gmail.com, pedrom.sousa@synopsys.com,
linux-arm-kernel@lists.infradead.org, beanhuo@micron.com
In-Reply-To: <1564044737.7235.9.camel@mtkswgap22>
Hi Avri,
On Thu, 2019-07-25 at 16:52 +0800, Stanley Chu wrote:
> Hi Avri,
>
> On Thu, 2019-07-25 at 07:54 +0000, Avri Altman wrote:
> > Stanly,
> >
> > >
> > > Currently bits in hba->outstanding_tasks are cleared only after their
> > > corresponding task management commands are successfully done by
> > > __ufshcd_issue_tm_cmd().
> > >
> > > If timeout happens in a task management command, its corresponding
> > > bit in hba->outstanding_tasks will not be cleared until next task
> > > management command with the same tag used successfully finishes.
> > I'm sorry - I still don't understand why you just can't release the tag either way,
> > Just like we do in device management queries tags,
> > Instead of adding all this unnecessary code.
> >
> > I will not object to your series -
> > just step down and let other people review you patches.
Sorry for late response due to these busy days.
I just got your point and agreed with you: previous proposal may be too
tricky. Simple always wins. So I will provide a short solution in next
version.
Many thanks!
Stanley
_______________________________________________
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 RESEND V2 5/7] clk: imx8mn: Add missing rate_count assignment for each PLL structure
From: Shawn Guo @ 2019-08-19 13:38 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd,
viresh.kumar, s.hauer, rjw, linux-kernel, linux-clk, robh+dt,
Linux-imx, kernel, leonard.crestez, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1566109945-11149-5-git-send-email-Anson.Huang@nxp.com>
On Sun, Aug 18, 2019 at 02:32:23AM -0400, Anson Huang wrote:
> Add .rate_count assignment which is necessary for searching required
> PLL rate from the each PLL table.
>
> Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver")
The commit ID is not stable before the commit lands on mainline, so I
dropped it and applied the patch.
Shawn
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V1:
> - split the patch into 2 patches, #1 fixed those missing .rate_count assignment,
> #2 add missing frequency points.
> ---
> drivers/clk/imx/clk-imx8mn.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/clk/imx/clk-imx8mn.c b/drivers/clk/imx/clk-imx8mn.c
> index ecd1062..b5a027c 100644
> --- a/drivers/clk/imx/clk-imx8mn.c
> +++ b/drivers/clk/imx/clk-imx8mn.c
> @@ -67,36 +67,43 @@ static const struct imx_pll14xx_rate_table imx8mn_drampll_tbl[] = {
> static struct imx_pll14xx_clk imx8mn_audio_pll = {
> .type = PLL_1443X,
> .rate_table = imx8mn_audiopll_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_audiopll_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_video_pll = {
> .type = PLL_1443X,
> .rate_table = imx8mn_videopll_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_videopll_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_dram_pll = {
> .type = PLL_1443X,
> .rate_table = imx8mn_drampll_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_drampll_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_arm_pll = {
> .type = PLL_1416X,
> .rate_table = imx8mn_pll1416x_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_gpu_pll = {
> .type = PLL_1416X,
> .rate_table = imx8mn_pll1416x_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_vpu_pll = {
> .type = PLL_1416X,
> .rate_table = imx8mn_pll1416x_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
> };
>
> static struct imx_pll14xx_clk imx8mn_sys_pll = {
> .type = PLL_1416X,
> .rate_table = imx8mn_pll1416x_tbl,
> + .rate_count = ARRAY_SIZE(imx8mn_pll1416x_tbl),
> };
>
> static const char * const pll_ref_sels[] = { "osc_24m", "dummy", "dummy", "dummy", };
> --
> 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
* Re: [PATCH RESEND V2 2/7] arm64: dts: imx8mn-ddr4-evk: Add rohm,bd71847 PMIC support
From: Shawn Guo @ 2019-08-19 13:36 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd,
viresh.kumar, s.hauer, rjw, linux-kernel, linux-clk, robh+dt,
Linux-imx, kernel, leonard.crestez, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1566109945-11149-2-git-send-email-Anson.Huang@nxp.com>
On Sun, Aug 18, 2019 at 02:32:20AM -0400, Anson Huang wrote:
> On i.MX8MN DDR4 EVK board, there is a rohm,bd71847 PMIC
> on i2c1 bus, enable it.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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 RESEND V2 1/7] arm64: dts: imx8mn-ddr4-evk: Add i2c1 support
From: Shawn Guo @ 2019-08-19 13:35 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, linux-pm, sboyd,
viresh.kumar, s.hauer, rjw, linux-kernel, linux-clk, robh+dt,
Linux-imx, kernel, leonard.crestez, festevam, mturquette,
linux-arm-kernel
In-Reply-To: <1566109945-11149-1-git-send-email-Anson.Huang@nxp.com>
On Sun, Aug 18, 2019 at 02:32:19AM -0400, Anson Huang wrote:
> Enable i2c1 on i.MX8MN DDR4 EVK board.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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] arm64: dts: renesas: ebisu, draak: Limit EtherAVB to 100Mbps
From: Geert Uytterhoeven @ 2019-08-19 13:35 UTC (permalink / raw)
To: Simon Horman
Cc: Andrew Lunn, Geert Uytterhoeven, Wolfram Sang, Magnus Damm,
Linux-Renesas, Kieran Bingham, Linux ARM
In-Reply-To: <20190729080356.13023-1-horms+renesas@verge.net.au>
On Mon, Jul 29, 2019 at 10:04 AM Simon Horman
<horms+renesas@verge.net.au> wrote:
> * According to the R-Car Gen3 Hardware Manual Errata for Rev 1.00 of
> August 24, 2018, the TX clock internal delay mode isn't supported
> on R-Car E3 (r8a77990) and D3 (r8a77995).
>
> * TX clock internal delay mode is required for reliable 1Gbps communication
> using the KSZ9031RNX phy present on the Ebisu and Draak boards.
>
> Thus, the E3 based Ebisu and D3 based Draak boards can not reliably
> use 1Gbps and the speed should be limited to 100Mbps.
>
> Based on work by Kazuya Mizuguchi.
>
> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Thanks, queuing in renesas-devel for v5.4.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
_______________________________________________
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: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Will Deacon @ 2019-08-19 13:34 UTC (permalink / raw)
To: Mark Rutland
Cc: Walter Wu, wsd_upstream, Catalin Marinas, Will Deacon,
linux-kernel, kasan-dev, linux-mediatek, Alexander Potapenko,
linux-arm-kernel, Andrey Konovalov, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <20190819132347.GB9927@lakrids.cambridge.arm.com>
On Mon, Aug 19, 2019 at 02:23:48PM +0100, Mark Rutland wrote:
> On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> > On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > > but it will modify pointer tag into 0xff, so there is a false positive.
> > >
> > > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > > its original pointer tag in order to avoid kasan report an incorrect
> > > memory corruption.
> >
> > Hmm. Which tree did you see this on? We've recently queued a load of fixes
> > in this area, but I /thought/ they were only needed after the support for
> > 52-bit virtual addressing in the kernel.
>
> I'm seeing similar issues in the virtio blk code (splat below), atop of
> the arm64 for-next/core branch. I think this is a latent issue, and
> people are only just starting to test with KASAN_SW_TAGS.
>
> It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
> virt->page->virt, losing the per-object tag in the process.
>
> Our page_to_virt() seems to get a per-page tag, but this only makes
> sense if you're dealing with the page allocator, rather than something
> like SLUB which carves a page into smaller objects giving each object a
> distinct tag.
>
> Any round-trip of a pointer from SLUB is going to lose the per-object
> tag.
Urgh, I wonder how this is supposed to work?
If we end up having to check the KASAN shadow for *_to_virt(), then why
do we need to store anything in the page flags at all? Andrey?
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 v2] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Thierry Reding @ 2019-08-19 13:33 UTC (permalink / raw)
To: Will Deacon
Cc: Marc Gonzalez, Joerg Roedel, Will Deacon, Douglas Anderson,
Jon Hunter, linux-tegra, Robin Murphy, Linux ARM
In-Reply-To: <20190819120917.hysyc6l3ckkwcx25@willie-the-truck>
[-- Attachment #1.1: Type: text/plain, Size: 2876 bytes --]
On Mon, Aug 19, 2019 at 01:09:18PM +0100, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 01:28:56PM +0200, Thierry Reding wrote:
> > Perhaps an alternative would be to add a property to the SMMU node that
> > lists a set of stream IDs for which to enable bypass by default. We
> > could let the firmware set that when the display hardware has been set
> > up. That way when the kernel boots we can keep scanning from the
> > reserved memory and the ARM SMMU driver would not disable bypass for the
> > display hardware. Only when the display hardware is actually attached to
> > the IOMMU domain, and the 1:1 mappings have been created would bypass be
> > disabled, and at that point there should be no SMMU faults anymore, so
> > we have cleanly transitioned to the kernel.
> >
> > Any thoughts?
>
> There is currently an extension to IORT under discussion which should
> address this problem, so it would make a lot of sense for the DT solution
> to follow the same approach. I think it will end up being along the lines
> that you suggest, although we won't just enable bypass because that leaves
> memory wide open if the device driver doesn't probe and it also creates
> an issue because device attach typically happens before the endpoint
> driver has probed.
>
> So the flow would look something like:
>
> - Firmware describes a physical region of memory which must be
> reserved by the OS.
>
> - Additionally, firmware describes a master -> reserved memory
> linkage as part of the IOMMU description.
>
> - When the IOMMU probes, these reserved memory regions will be
> mapped 1:1 for the relevant master.
>
> This is similar to RMRR on x86, except that the mappings are intended to
> be less rigid and can be torn down if the endpoint driver decides to do
> that or for things like device passthrough.
>
> If we get that working, we should update our booting.txt so that DMA is
> allowed during boot in the limited cases which this covers.
Hi Will,
that sounds very interesting. Is this extension being publicly
discussed? If so, do you have any pointers for me to read up on this? As
for device tree, I wonder if perhaps we can achieve this without going
through extra properties. We could, for example, just do a "reverse
lookup" of IOMMU masters by walking the device tree and looking for
nodes that link to an ARM SMMU in their iommus property. Granted, that's
not going to be very efficient, but it would remove the need to
duplicate information in DT. It's also going to be a one-time cost, so
perhaps it would be negligible.
I'm happy to help out with hashing out or implementing something on the
DT side of things. I don't currently have access to any systems with
ACPI, but I've got a bunch of systems that are DT based and that I would
like to see this implemented on.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- 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 03/11] clocksource: sun4i: Add missing compatibles
From: Maxime Ripard @ 2019-08-19 13:30 UTC (permalink / raw)
To: Daniel Lezcano
Cc: Mark Rutland, devicetree, Chen-Yu Tsai, Rob Herring, tglx,
Frank Rowand, linux-arm-kernel
In-Reply-To: <20190812112411.ty3npkq6ztbushhm@flea>
[-- Attachment #1.1: Type: text/plain, Size: 872 bytes --]
On Mon, Aug 12, 2019 at 01:24:11PM +0200, Maxime Ripard wrote:
> On Mon, Aug 12, 2019 at 11:21:50AM +0200, Daniel Lezcano wrote:
> > On 12/08/2019 11:16, Maxime Ripard wrote:
> > > Hi,
> > >
> > > On Mon, Aug 12, 2019 at 10:59:51AM +0200, Daniel Lezcano wrote:
> > >> On 22/07/2019 10:12, Maxime Ripard wrote:
> > >>> Newer Allwinner SoCs have different number of interrupts, let's add
> > >>> different compatibles for all of them to deal with this properly.
> > >>>
> > >>> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
> > >>
> > >> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
> > >
> > > Thanks!
> > >
> > > Can you merge this through your tree (along with the bindings)? I'll
> > > merge the DT patches
> >
> > patches 1-4 then ?
>
> Yep, thanks!
Ping?
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 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
* [PATCH v3] gpio: pl061: Fix the issue failed to register the ACPI interrtupion
From: Wei Xu @ 2019-08-19 13:27 UTC (permalink / raw)
To: xuwei5, linux-gpio, linux-kernel, linux-arm-kernel, linus.walleij,
rjw, lenb, mika.westerberg, andy.shevchenko
Cc: salil.mehta, jinying, tangkunshan, john.garry, linuxarm,
shameerali.kolothum.thodi, huangdaode, jonathan.cameron, liguozhu,
zhangyi.ac, shiju.jose
Invoke acpi_gpiochip_request_interrupts after the acpi data has been
attached to the pl061 acpi node to register interruption.
Otherwise it will be failed to register interruption for the ACPI case.
Because in the gpiochip_add_data_with_key, acpi_gpiochip_add is invoked
after gpiochip_add_irqchip but at that time the acpi data has not been
attached yet.
Tested with below steps:
qemu-system-aarch64 \
-machine virt,gic-version=3 -cpu cortex-a57 \
-m 1G,maxmem=4G,slots=4 \
-kernel Image -initrd rootfs.cpio.gz \
-net none -nographic \
-bios QEMU_EFI.fd \
-append "console=ttyAMA0 acpi=force earlycon=pl011,0x9000000"
The pl061 interruption is missed and the following output is not in the
/proc/interrupts on the v5.3-rc4 compared with the v5.2.0-rc7.
43: 0 ARMH0061:00 3 Edge ACPI:Event
Fixes: 04ce935c6b2a ("gpio: pl061: Pass irqchip when adding gpiochip")
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
---
v2 -> v3:
* addressed the comments of Andy to show only affected output of
/proc/interrupts and drop the whole log of v5.2.0-rc7
v1- > v2:
* rebased on https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=devel
* attached the log based on QEMU v3.0.0 and Linux kernel v5.2.0-rc7
---
drivers/gpio/gpio-pl061.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpio/gpio-pl061.c b/drivers/gpio/gpio-pl061.c
index 722ce5c..e1a434e 100644
--- a/drivers/gpio/gpio-pl061.c
+++ b/drivers/gpio/gpio-pl061.c
@@ -8,6 +8,7 @@
*
* Data sheet: ARM DDI 0190B, September 2000
*/
+#include <linux/acpi.h>
#include <linux/spinlock.h>
#include <linux/errno.h>
#include <linux/init.h>
@@ -24,6 +25,9 @@
#include <linux/pinctrl/consumer.h>
#include <linux/pm.h>
+#include "gpiolib.h"
+#include "gpiolib-acpi.h"
+
#define GPIODIR 0x400
#define GPIOIS 0x404
#define GPIOIBE 0x408
@@ -345,6 +349,9 @@ static int pl061_probe(struct amba_device *adev, const struct amba_id *id)
if (ret)
return ret;
+ if (has_acpi_companion(dev))
+ acpi_gpiochip_request_interrupts(&pl061->gc);
+
amba_set_drvdata(adev, pl061);
dev_info(dev, "PL061 GPIO chip registered\n");
--
2.8.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] arm64: dts: imx8mm: Enable cpu-idle driver
From: Shawn Guo @ 2019-08-19 13:25 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, devicetree, abel.vesa, daniel.baluta, s.hauer,
linux-kernel, jun.li, robh+dt, Linux-imx, kernel, leonard.crestez,
festevam, linux-arm-kernel, ping.bai
In-Reply-To: <1565950383-589-1-git-send-email-Anson.Huang@nxp.com>
On Fri, Aug 16, 2019 at 06:13:03AM -0400, Anson Huang wrote:
> Enable i.MX8MM cpu-idle using generic ARM cpu-idle driver, 2 states
> are supported, details as below:
>
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/name
> WFI
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state0/usage
> 3973
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/name
> cpu-pd-wait
> root@imx8mmevk:~# cat /sys/devices/system/cpu/cpu0/cpuidle/state1/usage
> 6647
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Applied, thanks.
_______________________________________________
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: kasan: fix phys_to_virt() false positive on tag-based kasan
From: Mark Rutland @ 2019-08-19 13:23 UTC (permalink / raw)
To: Will Deacon
Cc: Walter Wu, wsd_upstream, Catalin Marinas, Will Deacon,
linux-kernel, kasan-dev, linux-mediatek, Alexander Potapenko,
linux-arm-kernel, Andrey Konovalov, Matthias Brugger,
Andrey Ryabinin, Andrew Morton, Dmitry Vyukov
In-Reply-To: <20190819125625.bu3nbrldg7te5kwc@willie-the-truck>
On Mon, Aug 19, 2019 at 01:56:26PM +0100, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:44:20PM +0800, Walter Wu wrote:
> > __arm_v7s_unmap() call iopte_deref() to translate pyh_to_virt address,
> > but it will modify pointer tag into 0xff, so there is a false positive.
> >
> > When enable tag-based kasan, phys_to_virt() function need to rewrite
> > its original pointer tag in order to avoid kasan report an incorrect
> > memory corruption.
>
> Hmm. Which tree did you see this on? We've recently queued a load of fixes
> in this area, but I /thought/ they were only needed after the support for
> 52-bit virtual addressing in the kernel.
I'm seeing similar issues in the virtio blk code (splat below), atop of
the arm64 for-next/core branch. I think this is a latent issue, and
people are only just starting to test with KASAN_SW_TAGS.
It looks like the virtio blk code will round-trip a SLUB-allocated pointer from
virt->page->virt, losing the per-object tag in the process.
Our page_to_virt() seems to get a per-page tag, but this only makes
sense if you're dealing with the page allocator, rather than something
like SLUB which carves a page into smaller objects giving each object a
distinct tag.
Any round-trip of a pointer from SLUB is going to lose the per-object
tag.
Thanks,
Mark.
==================================================================
BUG: KASAN: double-free or invalid-free in virtblk_request_done+0x128/0x1d8 drivers/block/virtio_blk.c:215
Pointer tag: [ff], memory tag: [a8]
CPU: 0 PID: 19116 Comm: syz-executor.0 Not tainted 5.3.0-rc3-00075-gcb38552 #1
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x0/0x3c0 arch/arm64/include/asm/stacktrace.h:166
show_stack+0x24/0x30 arch/arm64/kernel/traps.c:138
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x138/0x1f4 lib/dump_stack.c:113
print_address_description+0x7c/0x328 mm/kasan/report.c:351
kasan_report_invalid_free+0x80/0xe0 mm/kasan/report.c:444
__kasan_slab_free+0x1a8/0x208 mm/kasan/common.c:56
kasan_slab_free+0xc/0x18 mm/kasan/common.c:457
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1474 [inline]
slab_free mm/slub.c:3016 [inline]
kfree+0x254/0x9dc mm/slub.c:3957
virtblk_request_done+0x128/0x1d8 drivers/block/virtio_blk.c:215
blk_done_softirq+0x3dc/0x49c block/blk-softirq.c:37
__do_softirq+0xa90/0x1504 kernel/softirq.c:292
do_softirq_own_stack include/linux/interrupt.h:549 [inline]
invoke_softirq kernel/softirq.c:380 [inline]
irq_exit+0x3b0/0x4f8 kernel/softirq.c:413
__handle_domain_irq+0x150/0x250 kernel/irq/irqdesc.c:671
atomic_read include/asm-generic/atomic-instrumented.h:26 [inline]
static_key_count include/linux/jump_label.h:254 [inline]
cpus_have_const_cap arch/arm64/include/asm/cpufeature.h:410 [inline]
gic_read_iar drivers/irqchip/irq-gic-v3.c:152 [inline]
gic_handle_irq+0x244/0x4ac drivers/irqchip/irq-gic-v3.c:490
el1_irq+0xbc/0x140 arch/arm64/kernel/entry.S:670
ktime_add_safe kernel/time/hrtimer.c:321 [inline]
hrtimer_set_expires_range_ns include/linux/hrtimer.h:235 [inline]
hrtimer_nanosleep kernel/time/hrtimer.c:1732 [inline]
__do_sys_nanosleep kernel/time/hrtimer.c:1767 [inline]
__se_sys_nanosleep kernel/time/hrtimer.c:1754 [inline]
__arm64_sys_nanosleep+0x344/0x554 kernel/time/hrtimer.c:1754
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common arch/arm64/kernel/syscall.c:114 [inline]
el0_svc_handler+0x300/0x540 arch/arm64/kernel/syscall.c:160
el0_svc+0x8/0xc arch/arm64/kernel/entry.S:1006
Allocated by task 170:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x114/0x1d0 mm/kasan/common.c:487
kasan_kmalloc+0x10/0x18 mm/kasan/common.c:501
__kmalloc+0x1f0/0x48c mm/slub.c:3811
kmalloc_array include/linux/slab.h:676 [inline]
virtblk_setup_discard_write_zeroes drivers/block/virtio_blk.c:188 [inline]
virtio_queue_rq+0x948/0xe48 drivers/block/virtio_blk.c:322
blk_mq_dispatch_rq_list+0x914/0x16fc block/blk-mq.c:1257
blk_mq_do_dispatch_sched+0x374/0x4d8 block/blk-mq-sched.c:115
blk_mq_sched_dispatch_requests+0x4d0/0x68c block/blk-mq-sched.c:216
__blk_mq_run_hw_queue+0x22c/0x35c block/blk-mq.c:1387
blk_mq_run_work_fn+0x64/0x78 block/blk-mq.c:1620
process_one_work+0x10bc/0x1df0 kernel/workqueue.c:2269
worker_thread+0x1124/0x17bc kernel/workqueue.c:2415
kthread+0x3c0/0x3d0 kernel/kthread.c:255
ret_from_fork+0x10/0x18 arch/arm64/kernel/entry.S:1164
Freed by task 17121:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x138/0x208 mm/kasan/common.c:449
kasan_slab_free+0xc/0x18 mm/kasan/common.c:457
slab_free_hook mm/slub.c:1423 [inline]
slab_free_freelist_hook mm/slub.c:1474 [inline]
slab_free mm/slub.c:3016 [inline]
kfree+0x254/0x9dc mm/slub.c:3957
kvfree+0x54/0x60 mm/util.c:488
__vunmap+0xa3c/0xafc mm/vmalloc.c:2255
__vfree mm/vmalloc.c:2299 [inline]
vfree+0xe4/0x1c4 mm/vmalloc.c:2329
copy_entries_to_user net/ipv6/netfilter/ip6_tables.c:883 [inline]
get_entries net/ipv6/netfilter/ip6_tables.c:1041 [inline]
do_ip6t_get_ctl+0xf78/0x1804 net/ipv6/netfilter/ip6_tables.c:1709
nf_sockopt net/netfilter/nf_sockopt.c:104 [inline]
nf_getsockopt+0x238/0x258 net/netfilter/nf_sockopt.c:122
ipv6_getsockopt+0x3374/0x40c4 net/ipv6/ipv6_sockglue.c:1400
tcp_getsockopt+0x214/0x54e0 net/ipv4/tcp.c:3662
sock_common_getsockopt+0xc8/0xf4 net/core/sock.c:3089
__sys_getsockopt net/socket.c:2129 [inline]
__do_sys_getsockopt net/socket.c:2144 [inline]
__se_sys_getsockopt net/socket.c:2141 [inline]
__arm64_sys_getsockopt+0x240/0x308 net/socket.c:2141
__invoke_syscall arch/arm64/kernel/syscall.c:36 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:48 [inline]
el0_svc_common arch/arm64/kernel/syscall.c:114 [inline]
el0_svc_handler+0x300/0x540 arch/arm64/kernel/syscall.c:160
el0_svc+0x8/0xc arch/arm64/kernel/entry.S:1006
The buggy address belongs to the object at ffff00005338eb80
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 0 bytes inside of
128-byte region [ffff00005338eb80, ffff00005338ec00)
The buggy address belongs to the page:
page:ffffffdffff4ce00 refcount:1 mapcount:0 mapping:e5ff0000576b0480 index:0x29ff000053388f00
flags: 0xffffff000000200(slab)
raw: 0ffffff000000200 ffffffdffff00108 5eff0000576afd40 e5ff0000576b0480
raw: 29ff000053388f00 000000000066005d 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff00005338e900: 34 34 34 34 34 34 34 34 fe fe fe fe fe fe fe fe
ffff00005338ea00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
>ffff00005338eb00: fe fe fe fe fe fe fe fe a8 fe fe fe fe fe fe fe
^
ffff00005338ec00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
ffff00005338ed00: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe
==================================================================
_______________________________________________
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] arm64: dts: ls1088a: fix gpio node
From: Shawn Guo @ 2019-08-19 13:20 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, linux-gpio, Linus Walleij, linux-kernel,
Li Yang, Bartosz Golaszewski, Rob Herring, linux-arm-kernel
In-Reply-To: <20190815103016.23125-1-hui.song_1@nxp.com>
On Thu, Aug 15, 2019 at 06:30:16PM +0800, Hui Song wrote:
> From: Song Hui <hui.song_1@nxp.com>
>
> Update the nodes to include little-endian
So the commit log needs an update as well?
Shawn
> property to be consistent with the hardware
> and add ls1088a gpio specify compatible.
>
> Signed-off-by: Song Hui <hui.song_1@nxp.com>
> ---
> Changes in v3:
> - delete the attribute of little-endian.
> Changes in v2:
> - update the subject.
>
> arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index dfbead4..ff669c8 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -269,7 +269,7 @@
> };
>
> gpio0: gpio@2300000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2300000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -280,7 +280,7 @@
> };
>
> gpio1: gpio@2310000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2310000 0x0 0x10000>;
> interrupts = <0 36 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -291,7 +291,7 @@
> };
>
> gpio2: gpio@2320000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2320000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> little-endian;
> @@ -302,7 +302,7 @@
> };
>
> gpio3: gpio@2330000 {
> - compatible = "fsl,qoriq-gpio";
> + compatible = "fsl,ls1088a-gpio", "fsl,qoriq-gpio";
> reg = <0x0 0x2330000 0x0 0x10000>;
> interrupts = <0 37 IRQ_TYPE_LEVEL_HIGH>;
> 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
* Re: [PATCH v2] arm64: dts: ls1088a: fix gpio node
From: Shawn Guo @ 2019-08-19 13:18 UTC (permalink / raw)
To: Hui Song
Cc: Mark Rutland, devicetree, Bartosz Golaszewski, Linus Walleij,
linux-kernel, Li Yang, linux-gpio, Rob Herring, linux-arm-kernel
In-Reply-To: <20190819114358.GX5999@X250>
On Mon, Aug 19, 2019 at 01:43:59PM +0200, Shawn Guo wrote:
> On Tue, Aug 13, 2019 at 10:04:57AM +0800, Hui Song wrote:
> > From: Song Hui <hui.song_1@nxp.com>
> >
> > Update the nodes to include little-endian
> > property to be consistent with the hardware
> > and add ls1088a gpio specify compatible.
> >
> > Signed-off-by: Song Hui <hui.song_1@nxp.com>
>
> Applied, thanks.
Just noticed there is a new version, so dropped this one.
Shawn
_______________________________________________
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 ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Andrey Konovalov @ 2019-08-19 13:16 UTC (permalink / raw)
To: Will Deacon
Cc: Mark Rutland, kvm, Szabolcs Nagy, Catalin Marinas, dri-devel,
Kostya Serebryany, Khalid Aziz,
open list:KERNEL SELFTEST FRAMEWORK, Felix Kuehling,
Vincenzo Frascino, Jacob Bramley, Leon Romanovsky, linux-rdma,
amd-gfx, Christoph Hellwig, Jason Gunthorpe, Linux ARM,
Dave Martin, Evgeniy Stepanov, linux-media, Kevin Brodsky,
Kees Cook, Ruben Ayrapetyan, Ramana Radhakrishnan,
Alex Williamson, Mauro Carvalho Chehab, Dmitry Vyukov,
Linux Memory Management List, Greg Kroah-Hartman, Yishai Hadas,
LKML, Jens Wiklander, Dan Carpenter, Lee Smith, Alexander Deucher,
Andrew Morton, enh, Robin Murphy, Christian Koenig,
Luc Van Oostenryck
In-Reply-To: <00eb8ba84205c59cac01b1b47615116a461c302c.1566220355.git.andreyknvl@google.com>
On Mon, Aug 19, 2019 at 3:14 PM Andrey Konovalov <andreyknvl@google.com> wrote:
>
> Fix tagged_ptr not being initialized when TBI is not enabled.
>
> Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> tools/testing/selftests/arm64/tags_test.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
> index 22a1b266e373..5701163460ef 100644
> --- a/tools/testing/selftests/arm64/tags_test.c
> +++ b/tools/testing/selftests/arm64/tags_test.c
> @@ -14,15 +14,17 @@
> int main(void)
> {
> static int tbi_enabled = 0;
> - struct utsname *ptr, *tagged_ptr;
> + unsigned long tag = 0;
> + struct utsname *ptr;
> int err;
>
> if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
> tbi_enabled = 1;
> ptr = (struct utsname *)malloc(sizeof(*ptr));
> if (tbi_enabled)
> - tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
> - err = uname(tagged_ptr);
> + tag = 0x42;
> + ptr = (struct utsname *)SET_TAG(ptr, tag);
> + err = uname(ptr);
> free(ptr);
>
> return err;
> --
> 2.23.0.rc1.153.gdeed80330f-goog
>
Hi Will,
This is supposed to go on top of the TBI related patches that you have
added to the arm tree.
Thanks!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH ARM] selftests, arm64: fix uninitialized symbol in tags_test.c
From: Andrey Konovalov @ 2019-08-19 13:14 UTC (permalink / raw)
To: linux-arm-kernel, linux-mm, linux-kernel, amd-gfx, dri-devel,
linux-rdma, linux-media, kvm, linux-kselftest, Will Deacon
Cc: Mark Rutland, Szabolcs Nagy, Catalin Marinas, Kostya Serebryany,
Khalid Aziz, Felix Kuehling, Vincenzo Frascino, Jacob Bramley,
Leon Romanovsky, Christoph Hellwig, Jason Gunthorpe, Dave Martin,
Evgeniy Stepanov, Kevin Brodsky, Kees Cook, Ruben Ayrapetyan,
Andrey Konovalov, Ramana Radhakrishnan, Alex Williamson,
Mauro Carvalho Chehab, Dmitry Vyukov, Greg Kroah-Hartman,
Yishai Hadas, Jens Wiklander, Dan Carpenter, Lee Smith,
Alexander Deucher, Andrew Morton, enh, Robin Murphy,
Christian Koenig, Luc Van Oostenryck
Fix tagged_ptr not being initialized when TBI is not enabled.
Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
tools/testing/selftests/arm64/tags_test.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/arm64/tags_test.c b/tools/testing/selftests/arm64/tags_test.c
index 22a1b266e373..5701163460ef 100644
--- a/tools/testing/selftests/arm64/tags_test.c
+++ b/tools/testing/selftests/arm64/tags_test.c
@@ -14,15 +14,17 @@
int main(void)
{
static int tbi_enabled = 0;
- struct utsname *ptr, *tagged_ptr;
+ unsigned long tag = 0;
+ struct utsname *ptr;
int err;
if (prctl(PR_SET_TAGGED_ADDR_CTRL, PR_TAGGED_ADDR_ENABLE, 0, 0, 0) == 0)
tbi_enabled = 1;
ptr = (struct utsname *)malloc(sizeof(*ptr));
if (tbi_enabled)
- tagged_ptr = (struct utsname *)SET_TAG(ptr, 0x42);
- err = uname(tagged_ptr);
+ tag = 0x42;
+ ptr = (struct utsname *)SET_TAG(ptr, tag);
+ err = uname(ptr);
free(ptr);
return err;
--
2.23.0.rc1.153.gdeed80330f-goog
_______________________________________________
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 v5] arm64: dts: ls1028a: Add esdhc node in dts
From: Shawn Guo @ 2019-08-19 13:10 UTC (permalink / raw)
To: Yinbo Zhu
Cc: Mark Rutland, devicetree, Ashish Kumar, linux-kernel, Li Yang,
Rob Herring, yangbo.lu, jiafei.pan, xiaobo.xie, linux-arm-kernel
In-Reply-To: <20190815033901.18696-1-yinbo.zhu@nxp.com>
On Thu, Aug 15, 2019 at 11:39:01AM +0800, Yinbo Zhu wrote:
> From: Ashish Kumar <Ashish.Kumar@nxp.com>
>
> This patch is to add esdhc node and enable SD UHS-I,
> eMMC HS200 for ls1028ardb/ls1028aqds board.
>
> Signed-off-by: Ashish Kumar <Ashish.Kumar@nxp.com>
> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Applied, thanks.
_______________________________________________
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 0/4] arm64: KPROBES_ON_FTRACE
From: Masami Hiramatsu @ 2019-08-19 13:10 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Catalin Marinas, x86@kernel.org, linux-kernel@vger.kernel.org,
Anil S Keshavamurthy, Ingo Molnar, Borislav Petkov,
Steven Rostedt, H. Peter Anvin, Naveen N. Rao, Thomas Gleixner,
Will Deacon, David S. Miller,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190819192422.5ed79702@xhacker.debian>
Hi Jisheng,
On Mon, 19 Aug 2019 11:35:27 +0000
Jisheng Zhang <Jisheng.Zhang@synaptics.com> wrote:
> Implement KPROBES_ON_FTRACE for arm64.
>
> Applied after FTRACE_WITH_REGS:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2019-August/674404.html
Looks interesting! thanks for working on it.
I'll check it.
Thanks,
>
> Jisheng Zhang (4):
> kprobes: adjust kprobe addr for KPROBES_ON_FTRACE
> kprobes/x86: use instruction_pointer and instruction_pointer_set
> kprobes: move kprobe_ftrace_handler() from x86 and make it weak
> arm64: implement KPROBES_ON_FTRACE
>
> arch/arm64/Kconfig | 1 +
> arch/arm64/kernel/probes/Makefile | 1 +
> arch/arm64/kernel/probes/ftrace.c | 16 +++++++++++
> arch/x86/kernel/kprobes/ftrace.c | 43 ----------------------------
> kernel/kprobes.c | 47 +++++++++++++++++++++++++++++++
> 5 files changed, 65 insertions(+), 43 deletions(-)
> create mode 100644 arch/arm64/kernel/probes/ftrace.c
>
> --
> 2.23.0.rc1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
_______________________________________________
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: dts: imx8mn: Add gpio-ranges property
From: Shawn Guo @ 2019-08-19 13:09 UTC (permalink / raw)
To: Anson.Huang
Cc: mark.rutland, devicetree, abel.vesa, daniel.baluta, s.hauer,
linux-kernel, robh+dt, Linux-imx, kernel, leonard.crestez,
festevam, linux-arm-kernel, jun.li
In-Reply-To: <1565837850-1373-1-git-send-email-Anson.Huang@nxp.com>
On Wed, Aug 14, 2019 at 10:57:30PM -0400, Anson.Huang@nxp.com wrote:
> From: Anson Huang <Anson.Huang@nxp.com>
>
> Add "gpio-ranges" property to establish connections between GPIOs
> and PINs on i.MX8MN pinctrl driver.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Applied, thanks.
_______________________________________________
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