* [PATCH 02/37] perf event: Check ref_reloc_sym before using it
From: Arnaldo Carvalho de Melo @ 2019-08-29 14:38 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner
Cc: Arnaldo Carvalho de Melo, Mathieu Poirier, Suzuki Poulouse,
Clark Williams, Alexey Budankov, Igor Lubashev, linux-kernel,
James Morris, linux-perf-users, Alexander Shishkin,
Peter Zijlstra, Jiri Olsa, Namhyung Kim, linux-arm-kernel
In-Reply-To: <20190829143917.29745-1-acme@kernel.org>
From: Igor Lubashev <ilubashe@akamai.com>
Check for ref_reloc_sym before using it instead of checking
symbol_conf.kptr_restrict and relying solely on that check.
Reported-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Igor Lubashev <ilubashe@akamai.com>
Tested-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
Cc: James Morris <jmorris@namei.org>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Link: http://lkml.kernel.org/r/1566869956-7154-2-git-send-email-ilubashe@akamai.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/event.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 33616ea62a47..e33dd1a040cc 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -913,11 +913,13 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
int err;
union perf_event *event;
- if (symbol_conf.kptr_restrict)
- return -1;
if (map == NULL)
return -1;
+ kmap = map__kmap(map);
+ if (!kmap->ref_reloc_sym)
+ return -1;
+
/*
* We should get this from /sys/kernel/sections/.text, but till that is
* available use this, and after it is use this as a fallback for older
@@ -940,7 +942,6 @@ static int __perf_event__synthesize_kernel_mmap(struct perf_tool *tool,
event->header.misc = PERF_RECORD_MISC_GUEST_KERNEL;
}
- kmap = map__kmap(map);
size = snprintf(event->mmap.filename, sizeof(event->mmap.filename),
"%s%s", machine->mmap_name, kmap->ref_reloc_sym->name) + 1;
size = PERF_ALIGN(size, sizeof(u64));
--
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
* Re: [PATCH v3 0/3] arm64: meson-sm1: add support for the SM1 based VIM3L
From: Neil Armstrong @ 2019-08-29 14:39 UTC (permalink / raw)
To: Kevin Hilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel
In-Reply-To: <7hblw9rx8f.fsf@baylibre.com>
On 28/08/2019 19:55, Kevin Hilman wrote:
> Neil Armstrong <narmstrong@baylibre.com> writes:
>
>> This patchset adds support for the Amlogic SM1 based Khadas VIM3L variant.
>>
>> The S903D3 package variant of SM1 is pin-to-pin compatible with the
>> S922X and A311d, so only internal DT changes are needed :
>> - DVFS support is different
>> - Audio support not yet available for SM1
>>
>> This patchset moved all the non-g12b nodes to meson-khadas-vim3.dtsi
>> and add the sm1 specific nodes into meson-sm1-khadas-vim3l.dts.
>
> Reviewed-by: Kevin Hilman <khilman@baylibre.com>
> Tested-by: Kevin Hilman <khilman@baylibre.com>
>
> Basic boot test + suspend/resume test OK on my vim3L (thanks to Khadas
> for the board!)
>
>> Display has a color conversion bug on SM1 by using a more recent vendor
>> bootloader on the SM1 based VIM3, this is out of scope of this patchset
>> and will be fixed in the drm/meson driver.
>>
>> Dependencies:
>> - patch 1,2: None
>> - patch 3: Depends on the "arm64: meson-sm1: add support for DVFS" patchset at [1]
>
> I tested in my integ branch where this series is applied, but I'm not
> seeing any OPPs created (/sys/devices/system/cpu/cpufreq/)
These patches were sent from your integ branch, on top of :
commit 395df5af4c782ad19fb34b9a2009ca240eeb9749 (khilman-amlogic/v5.4/integ)
Merge: 2fcc5666dd45 9557737987bb
Author: Kevin Hilman <khilman@baylibre.com>
Date: Tue Aug 27 15:39:46 2019 -0700
Merge branch 'v5.4/testing' into tmp/aml-rebuild
Rebuilt and retested, and I get the OPPs just fine :
# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
100000 250000 500000 666666 1000000 1200000 1404000 1500000 1608000 1704000 1800000 1908000
Here is the boot log:
https://pastebin.com/LY21gU9E
and .config:
https://termbin.com/1s5g
Neil
>
> Kevin
>
_______________________________________________
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 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: robin @ 2019-08-29 14:32 UTC (permalink / raw)
To: Marco Felsch
Cc: Mark Rutland, devicetree @ vger . kernel . org, Fabio Estevam,
Adam Ford, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Robin Gong, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <20190829115052.s2m4jw4p3rknqoxb@pengutronix.de>
On 2019-08-29 13:50, Marco Felsch wrote:
> On 19-08-29 09:11, Robin Gong wrote:
>>
>> On 2019-08-29 16:17, Marco Felsch wrote:
>> > > > While reading the rm it seems that
>> > > > the snvs block has a dedicated version register. IMHO this could be
>> > > > a better way to apply the change also to existing devices with old
>> > > > firmware.
>> > >
>> > > I thought the same thing, and fully agree with you. However I do not
>> > > have a way to determine which versions are out there. Since I couldn't
>> > > find any documentation on this, and I only have i.MX6 S/DL, D/Q and UL
>> > laying around.
>> >
>> > @NXP Kernel Team
>> > Can we get some more information here?
>> Go ahead, please. That snvs version register SNVS_HPVIDR1 should work
>> as expect.
>> MINOR_REV checking is enough, none-zero means for soc after i.mx6sx,
>> but
>> Zero means i.mx6q/dl/sl elder soc.
>
> Thanks. Robin can you integrate that so we can drop the different
> dt-handling?
No problem, I'll post an updated patch tomorrow.
>
> Regards,
> Marco
>
>> >
>> > Regards,
>> > Marco
>> >
>> > > Regards,
>> > > Robin van der Gracht
>> > >
>> >
>> > --
>> > Pengutronix e.K. |
>> > |
>> > Industrial Linux Solutions |
>> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p
>> > engutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7C8d4e1
>> > 0cd77bd4652f3eb08d72c594e76%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
>> > C0%7C0%7C637026634390359345&sdata=mhXlUxmLWg8qtwhPQfkJZm
>> > VAn4QQ3YybLOSh83uf27E%3D&reserved=0 |
>> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
>> > |
>> > Amtsgericht Hildesheim, HRA 2686 | Fax:
>> > +49-5121-206917-5555 |
>>
_______________________________________________
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/6] Fix TLB invalidation on arm64
From: Nicholas Piggin @ 2019-08-29 14:08 UTC (permalink / raw)
To: Will Deacon
Cc: linux-arch, Mark Rutland, Peter Zijlstra, Catalin Marinas,
Marc Zyngier, linux-arm-kernel
In-Reply-To: <20190828161256.uevoohval4sko24m@willie-the-truck>
Will Deacon's on August 29, 2019 2:12 am:
> Hi Nick,
>
> On Wed, Aug 28, 2019 at 10:35:24AM +1000, Nicholas Piggin wrote:
>> Will Deacon's on August 27, 2019 11:18 pm:
>> > So far, so good, but the final piece of the puzzle isn't quite so rosy.
>> >
>> > *** Other architecture maintainers -- start here! ***
>> >
>> > In the case that one CPU maps a page and then sets a flag to tell another
>> > CPU:
>> >
>> > CPU 0
>> > -----
>> >
>> > MOV X0, <valid pte>
>> > STR X0, [Xptep] // Store new PTE to page table
>> > DSB ISHST
>> > ISB
>> > MOV X1, #1
>> > STR X1, [Xflag] // Set the flag
>> >
>> > CPU 1
>> > -----
>> >
>> > loop: LDAR X0, [Xflag] // Poll flag with Acquire semantics
>> > CBZ X0, loop
>> > LDR X1, [X2] // Translates using the new PTE
>> >
>> > then the final load on CPU 1 can raise a translation fault for the same
>> > reasons as mentioned at the start of this description.
>>
>> powerpc's ptesync instruction is defined to order MMU memory accesses on
>> all other CPUs. ptesync does not go out to the fabric though. How does
>> it work then?
>>
>> Because the MMU coherency problem (at least we have) is not that the
>> load will begin to "partially" execute ahead of the store, enough to
>> kick off a table walk that goes ahead of the store, but not so much
>> that it violates the regular CPU barriers. It's just that the loads
>> from the MMU don't participate in the LSU pipeline, they don't snoop
>> the store queues aren't inserted into load queues so the regular
>> memory barrier instructions won't see stores from other threads cuasing
>> ordering violations.
>>
>> In your first example, if powerpc just has a normal memory barrier
>> there instead of a ptesync, it could all execute completely
>> non-speculatively and in-order but still cause a fault, because the
>> table walker's loads didn't see the store in the store queue.
>
> Ah, so I think this is where our DSB comes in, as opposed to our usual
> DMB. DMB provides ordering guarantees and is generally the only barrier
> instruction you need for shared memory communication. DSB, on the other
> hand, has additional properties such as making page-table updates visible
> to the table walker and completing pending TLB invalidation.
>
> So in practice, DSB is likely to drain the store buffer to ensure that
> pending page-table writes are visible at L1, which is coherent with all
> CPUs (and their page-table walkers).
>
>> From the other side of the fabric you have no such problem. The table
>> walker is cache coherent apart from the local stores, so we don't need a
>> special barrier on the other side. That's why ptesync doesn't broadcast.
>
> Curious: but do you need to do anything extra to take into account
> instruction fetch on remote CPUs if you're mapping an executable page?
> We added an IPI to flush_icache_range() in 3b8c9f1cdfc5 to handle this,
> because our broadcast I-cache maintenance doesn't force a pipeline flush
> for remote CPUs (and may even execute as a NOP on recent cores).
Ah, I think the tlbie does not force re-fetch indeed. We may need
something like that as well.
What do you do on the user side? Require threads to ISB themselves?
>> I would be surprised if ARM's issue is different, but interested to
>> hear if it is.
>
> If you take the four scenarios of Map/Unmap for the UP/SMP cases:
>
> Map+UP // Some sort of fence instruction (DSB;ISB/ptesync)
> Map+SMP // Same as above
> Unmap+UP // Local TLB invalidation
> Unmap+SMP // Broadcast TLB invalidation
>
> then the most interesting case is Map+SMP, where one CPU transitions a PTE
> from invalid to valid and executes its DSB;ISB/PTESYNC sequence without
> affecting the remote CPU. That's what I'm trying to get at in my example
> below:
>
>> > CPU 0 CPU 1
>> > ----- -----
>> > spin_lock(&lock); spin_lock(&lock);
>> > set_fixmap(0, paddr, prot); if (mapped)
>> > mapped = true; foo = *fix_to_virt(0);
>> > spin_unlock(&lock); spin_unlock(&lock);
>> >
>> > could fault.
>>
>> This is kind of a different issue, or part of a wider one at least.
>> Consider speculative execution more generally, any branch mispredict can
>> send us off to crazy town executing instructions using nonsense register
>> values. CPU0 does not have to be in the picture, or any kernel page
>> table modification at all, CPU1 alone will be doing speculative loads
>> wildly all over the kernel address space and trying to access pages with
>> no pte.
>>
>> Yet we don't have to flush TLB when creating a new kernel mapping, and
>> we don't get spurious kernel faults. The page table walker won't
>> install negative entries, at least not "architectural" i.e., that cause
>> faults and require flushing. My guess is ARM is similar, or you would
>> have seen bigger problems by now?
>
> Right, we don't allow negative (invalid) entries to be cached in the TLB,
> but CPUs can effectively cache the result of a translation for a load/store
> instruction whilst that instruction flows down the pipe after its virtual
> address is known. /That/ caching is not restricted to valid translations.
Ah, I misunderstood you sorry. Yeah that is interesting, I don't think
that is explicitly prohibited in the power ISA either. I believe CPU1
would have to do a ptesync to avoid the fault there.
> For example, if we just take a simple message passing example where we have
> two global variables: a 'mapped' flag (initialised to zero) and a pointer
> (initialised to point at a page that is not yet mapped):
>
> [please excuse the mess I've made of your assembly language]
>
> CPU 0
>
> // Set PTE which maps the page pointed to by pointer
> stw r5, 0(r4)
> ptesync
> lwsync
>
> // Set 'mapped' flag to 1
> li r9, 1
> stb r9, 0(r3)
>
>
> CPU 1
>
> // Poll for 'mapped' flag to be set
> loop: lbz r9, 0(r3)
> lwsync
> cmpdi cr7, r0, 0
> beq cr7, loop
>
> // Dereference pointer
> lwz r4, 0(r5)
>
>
> So in this example, I think it's surprising that CPU 1's dereference of
> 'pointer' can fault. The way this happens on arm64 is that CPU 1 can
> translate the 'pointer' dereference before the load of the 'mapped' flag has
> returned its data. The walker may come back with a fault, but then if the
> flag data later comes back as 1, the fault will be taken when the lwz
> commits. In other words, translation table walks can occur out-of-order
> with respect to the accesses they are translating for, even in the presence
> of memory barriers.
>
> In practice, I think this kind of code sequence is unusual and triggering
> the problem relies on CPU 1 knowing the virtual address it's going to
> dereference before it's actually mapped. However, this could conceivably
> happen with the fixmap and possibly also if the page-table itself was
> being written concurrently using cmpxchg(), in which case you might use
> the actual pte value in the same way as the 'mapped' flag above.
>
> But yes, adding the spurious fault handler is belt and braces, which is
> why I've kept a WARN_RATELIMIT() in there if it ever triggers.
This could be a theoretical problem for powerpc too, I think. Maybe.
I'll ask around, I might not be understanding the architecture or Linux
code properly.
Thanks,
Nick
_______________________________________________
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/arm64: defconfig: Update configs to use the new CROS_EC options
From: Enric Balletbo i Serra @ 2019-08-29 13:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Gwendal Grignou, Collabora kernel ML, Geert Uytterhoeven,
Tony Lindgren, Catalin Marinas, Linus Walleij, Bjorn Andersson,
Thierry Reding, Miquel Raynal, Guenter Roeck, Leonard Crestez,
Will Deacon, Marek Szyprowski, Maxime Ripard,
moderated list:ARM/SAMSUNG EXYNOS ARM ARCHITECTURES, Anson Huang,
Lee Jones, Dan iel Lezcano, Russell King, Krzysztof Kozlowski,
Jonathan Hunter, Marcin Juszkiewicz, Chanwoo Choi, Kukjin Kim,
Jagan Teki, Alexandre Torgue, Robert Jarzmik, SoC Team,
open list:TEGRA ARCHITECTURE SUPPORT, Simon Horman,
Fabrice Gasnier, Benson Leung, Linux ARM,
Linux Kernel Mailing List, Yannick Fertr?, Dinh Nguyen,
Sudeep Holla, Olof Johansson, Shawn Guo, Daniel Mack
In-Reply-To: <CAK8P3a3zYpgouGAibyMjDykZmy+ABnx6AD2cYpHnXq9Zsw2V=w@mail.gmail.com>
Hi,
On 28/8/19 14:09, Arnd Bergmann wrote:
> On Wed, Aug 28, 2019 at 12:10 PM Enric Balletbo i Serra
> <enric.balletbo@collabora.com> wrote:
>> On 27/8/19 18:12, Arnd Bergmann wrote:
>>> On Tue, Aug 27, 2019 at 6:08 PM Bjorn Andersson
>>> <bjorn.andersson@linaro.org> wrote:
>>>>
>>>> On Tue 27 Aug 08:48 PDT 2019, Enric Balletbo i Serra wrote:
>>>>
>>>>> Recently we refactored the CrOS EC drivers moving part of the code from
>>>>> the MFD subsystem to the platform chrome subsystem. During this change
>>>>> we needed to rename some config options, so, update the defconfigs
>>>>> accordingly.
>>>>>
>>>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
>>>>> Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
>>>>> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
>>>>> Tested-by: Gwendal Grignou <gwendal@chromium.org>
>>>>
>>>> Can we make the entries in the generic arm64 defconfig modules?
>>>
>>> Good idea.
>>>
>>> Actually I would prefer to have all of them as modules for consistency,
>>> if at all possible.
>>>
>>
>> It is very common boot Chromebooks from an USB device, the EC needs to be
>> built-in in order to boot from these devices, otherwise you should use an
>> initramfs. I'd like to avoid forcing people to build an initramfs just to boot
>> from these devices if possible, in fact, my usual workflow is without initramfs,
>> and knowing that with the default defconfig just should boot helps a lot sometimes.
>>
>> Note that, it's not the case for EC subdevices, these are already build as modules.
>
> Ok, fair enough, let's leave it built-in then.
>
>> BTW, Lee asked if this patch should be squashed with the patches that really
>> renames the config options to help bisect ability, I don't have a hard opinion
>> as I don't usually run the config option between bisection steps, so please let
>> me know what do you prefer and I'll respin the patches ASAP if that's the case.
>
> I'm not usually worried about bisection in defconfig changes, since like you
> say most commonly one would not run 'make defconfig' betweens the
> bisection steps.
>
> If we really care about it, we could keep a symbol like this
> in drivers/platform/chrome/Kconfig for one release:
>
> config CONFIG_MFD_CROS_EC
> tristate "Enable ChromeOS Embedded Controller"
> select CROS_EC
> select CHROME_PLATFORMS
> select CONFIG_MFD_CROS_EC_DEV
> help
> This is a transitional Kconfig option and will be removed
> after everyone enables the parts individually.
>
Not sure if really makes sense do this and tbh and don't have a hard opinion, so
I'll let the final decision to the soc/mfd maintainers. Just let me know and
I'll respin the patches with that if you really want.
Thanks,
Enric
> Arnd
>
_______________________________________________
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] [RFC] tty/serial: imx: make use of format specifier %dE
From: Andy Shevchenko @ 2019-08-29 13:43 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Jani Nikula, Petr Mladek, open list:SERIAL DRIVERS,
Jonathan Corbet, Greg Kroah-Hartman, Linux Documentation List,
Linux Kernel Mailing List, Steven Rostedt, Enrico Weigelt,
NXP Linux Team, Sascha Hauer, Jiri Slaby, Shawn Guo,
Andrew Morton, Fabio Estevam, linux-arm Mailing List,
Sergey Senozhatsky
In-Reply-To: <20190829043716.5223-1-uwe@kleine-koenig.org>
On Thu, Aug 29, 2019 at 7:40 AM Uwe Kleine-König <uwe@kleine-koenig.org> wrote:
>
> I created a patch that teaches printk et al to emit a symbolic error
> name for an error valued integer[1]. With that applied
>
> dev_err(&pdev->dev, "failed to get ipg clk: %dE\n", ret);
>
> emits
>
> ... failed to get ipg clk: EPROBE_DEFER
>
> if ret is -EPROBE_DEFER. Petr Mladek (i.e. one of the printk
> maintainers) had concerns if this would be well received and worth the
> effort. He asked to present it to a few subsystems. So for now, this
> patch converting the imx UART driver shouldn't be applied yet but it
> would be great to get some feedback about if you think that being able
> to easily printk (for example) "EIO" instead of "-5" is a good idea.
> Would it help you? Do you think it helps your users?
No, it makes sense only for debug where the user is supposed to be
developer and thus needs anyway to know code base better than average.
--
With Best Regards,
Andy Shevchenko
_______________________________________________
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] mmc: mediatek: enable SDIO IRQ low level trigger function
From: Ulf Hansson @ 2019-08-29 13:36 UTC (permalink / raw)
To: Yong Mao
Cc: srv_heupstream, linux-mmc@vger.kernel.org,
Linux Kernel Mailing List, linux-mediatek, Chaotian Jing,
Matthias Brugger, Linux ARM
In-Reply-To: <1566985524-22749-2-git-send-email-yong.mao@mediatek.com>
On Wed, 28 Aug 2019 at 11:45, Yong Mao <yong.mao@mediatek.com> wrote:
>
> From: yong mao <yong.mao@mediatek.com>
>
> SDIO IRQ is not defaultly triggered by low level,
> but by falling edge. It needs to set related register
> to enable SDIO IRQ low level trigger function.
> Otherwise the SDIO IRQ may be lost in some specail condition.
>
> Signed-off-by: Yong Mao <yong.mao@mediatek.com>
> Signed-off-by: Chaotian Jing <chaotian.jing@mediatek.com>
Applied for next, thanks!
Kind regards
Uffe
> ---
> drivers/mmc/host/mtk-sd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
> index 33f4b63..585f0c7 100644
> --- a/drivers/mmc/host/mtk-sd.c
> +++ b/drivers/mmc/host/mtk-sd.c
> @@ -192,6 +192,7 @@
> #define SDC_STS_CMDBUSY (0x1 << 1) /* RW */
> #define SDC_STS_SWR_COMPL (0x1 << 31) /* RW */
>
> +#define SDC_DAT1_IRQ_TRIGGER (0x1 << 19) /* RW */
> /* SDC_ADV_CFG0 mask */
> #define SDC_RX_ENHANCE_EN (0x1 << 20) /* RW */
>
> @@ -1568,6 +1569,7 @@ static void msdc_init_hw(struct msdc_host *host)
>
> /* Config SDIO device detect interrupt function */
> sdr_clr_bits(host->base + SDC_CFG, SDC_CFG_SDIOIDE);
> + sdr_set_bits(host->base + SDC_ADV_CFG0, SDC_DAT1_IRQ_TRIGGER);
>
> /* Configure to default data timeout */
> sdr_set_field(host->base + SDC_CFG, SDC_CFG_DTOC, 3);
> --
> 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
* [PATCH] arm64: dts: meson-sm1-sei610: add stdout-path property back
From: Neil Armstrong @ 2019-08-29 13:27 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
The commit d4609acce187 ("arm64: dts: meson-sm1-sei610: enable DVFS")
incorrectly removed the chosen node and the stdout-path property.
Add these back.
Fixes: d4609acce187 ("arm64: dts: meson-sm1-sei610: enable DVFS")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
index e1cac880b02c..3435aaa4e8db 100644
--- a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
@@ -19,6 +19,10 @@
ethernet0 = ðmac;
};
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
--
2.22.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: [PATCHv2 05/11] soc: ti: omap-prm: sync func clock status with resets
From: Philipp Zabel @ 2019-08-29 13:25 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <20190828071941.32378-6-t-kristo@ti.com>
On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
> Hardware reset signals are tightly coupled with associated clocks, and
> basically de-asserting a reset won't succeed properly if the clock is
> not enabled, and vice-versa. Also, disabling a clock won't fully succeed
> if the associated hardware resets are not asserted. Add status sync
> functionality between these two for TI drivers so that the situations
> can be handled properly without generating any timeouts.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index 38998ce19c71..e876bad8f8d5 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -15,6 +15,8 @@
> #include <linux/platform_device.h>
> #include <linux/reset-controller.h>
> #include <linux/delay.h>
> +#include <linux/clk.h>
> +#include <linux/clk/ti.h>
>
> #include <linux/platform_data/ti-prm.h>
>
> @@ -42,7 +44,9 @@ struct omap_reset_data {
> struct reset_controller_dev rcdev;
> struct omap_prm *prm;
> struct clockdomain *clkdm;
> + struct clk *clk;
> struct device *dev;
> + u32 mask;
> };
>
> #define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
> @@ -102,6 +106,8 @@ static int omap_reset_assert(struct reset_controller_dev *rcdev,
> v |= 1 << id;
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>
> + ti_clk_notify_resets(reset->clk, v == reset->mask);
> +
> return 0;
> }
>
> @@ -163,9 +169,19 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> v &= ~(1 << id);
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>
> + ti_clk_notify_resets(reset->clk, v == reset->mask);
> +
> if (!has_rstst)
> goto exit;
>
> + /* If associated clock is disabled, we can't poll completion status */
> + if (reset->clk) {
> + struct clk_hw *hw = __clk_get_hw(reset->clk);
> +
> + if (!clk_hw_is_enabled(hw))
> + return ret;
> + }
> +
> /* wait for the status to be set */
> while (1) {
> v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
> @@ -199,8 +215,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
> struct omap_prm *prm)
> {
> struct omap_reset_data *reset;
> + const struct omap_rst_map *map;
> struct ti_prm_platform_data *pdata = dev_get_platdata(&pdev->dev);
> char buf[32];
> + u32 v;
>
> /*
> * Check if we have controllable resets. If either rstctrl is non-zero
> @@ -215,6 +233,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
> !pdata->clkdm_allow_idle)
> return -EINVAL;
>
> + map = prm->data->rstmap;
> + if (!map)
> + return -EINVAL;
Can this actually happen?
> +
> reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
> if (!reset)
> return -ENOMEM;
> @@ -224,6 +246,10 @@ static int omap_prm_reset_init(struct platform_device *pdev,
> reset->rcdev.of_node = pdev->dev.of_node;
> reset->rcdev.nr_resets = OMAP_MAX_RESETS;
> reset->dev = &pdev->dev;
> + reset->clk = of_clk_get(pdev->dev.of_node, 0);
> +
> + if (IS_ERR(reset->clk))
> + reset->clk = NULL;
Maybe only ignore -ENOENT?
> reset->prm = prm;
>
> @@ -234,6 +260,16 @@ static int omap_prm_reset_init(struct platform_device *pdev,
> if (!reset->clkdm)
> return -EINVAL;
>
> + while (map->rst >= 0) {
> + reset->mask |= BIT(map->rst);
> + map++;
> + }
With this, you could use reset->mask to simplify _is_valid_reset.
regards
Philipp
_______________________________________________
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 v11 7/8] open: openat2(2) syscall
From: Aleksa Sarai @ 2019-08-29 13:19 UTC (permalink / raw)
To: Rasmus Villemoes
Cc: linux-ia64, linux-sh, Alexei Starovoitov, linux-kernel,
David Howells, open list:KERNEL SELFTEST FRAMEWORK, sparclinux,
Shuah Khan, linux-arch, linux-s390, Daniel Colascione,
Aleksa Sarai, linux-arm-kernel, linux-mips, linux-xtensa,
Kees Cook, Arnd Bergmann, Jann Horn, Tycho Andersen, linux-m68k,
Al Viro, Andy Lutomirski, Shuah Khan, David Drysdale,
Christian Brauner, J. Bruce Fields, linux-parisc, Linux API,
Chanho Min, linuxppc-dev, Jeff Layton, Oleg Nesterov,
Eric Biederman, linux-alpha, Linux FS Devel, Andrew Morton,
Linus Torvalds, containers
In-Reply-To: <899401fa-ff0a-2ce9-8826-09904efab2d2@rasmusvillemoes.dk>
[-- Attachment #1.1: Type: text/plain, Size: 3601 bytes --]
On 2019-08-29, Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote:
> On 29/08/2019 14.15, Aleksa Sarai wrote:
> > On 2019-08-24, Daniel Colascione <dancol@google.com> wrote:
>
> >> Why pad the structure when new functionality (perhaps accommodated via
> >> a larger structure) could be signaled by passing a new flag? Adding
> >> reserved fields to a structure with a size embedded in the ABI makes a
> >> lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
> >> can grow, so the reservation seems needless to me.
> >
> > Quite a few folks have said that ->reserved is either unnecessary or
> > too big. I will be changing this, though I am not clear what the best
> > way of extending the structure is. If anyone has a strong opinion on
> > this (or an alternative to the ones listed below), please chime in. I
> > don't have any really strong attachment to this aspect of the API.
> >
> > There appear to be a few ways we can do it (that all have precedence
> > with other syscalls):
> >
> > 1. Use O_* flags to indicate extensions.
> > 2. A separate "version" field that is incremented when we change.
> > 3. Add a size_t argument to openat2(2).
> > 4. Reserve space (as in this patchset).
> >
> > (My personal preference would be (3), followed closely by (2).)
>
> 3, definitely, and instead of having to invent a new scheme for every
> new syscall, make that the default pattern by providing a helper
Sure (though hopefully I don't need to immediately go and refactor all
the existing size_t syscalls). I will be presenting about this patchset
at the containers microconference at LPC (in a few weeks), so I'll hold
of on any API-related rewrites until after that.
> int __copy_abi_struct(void *kernel, size_t ksize, const void __user
> *user, size_t usize)
> {
> size_t copy = min(ksize, usize);
>
> if (copy_from_user(kernel, user, copy))
> return -EFAULT;
>
> if (usize > ksize) {
> /* maybe a separate "return user_is_zero(user + ksize, usize -
> ksize);" helper */
> char c;
> user += ksize;
> usize -= ksize;
> while (usize--) {
> if (get_user(c, user++))
> return -EFAULT;
> if (c)
> return -EINVAL;
This part would probably be better done with memchr_inv() and
copy_from_user() (and probably should put an upper limit on usize), but
I get what you mean.
> }
> } else if (ksize > usize) {
> memset(kernel + usize, 0, ksize - usize);
> }
> return 0;
> }
> #define copy_abi_struct(kernel, user, usize) \
> __copy_abi_struct(kernel, sizeof(*kernel), user, usize)
>
> > Both (1) and (2) have the problem that the "struct version" is inside
> > the struct so we'd need to copy_from_user() twice. This isn't the end of
> > the world, it just feels a bit less clean than is ideal. (3) fixes that
> > problem, at the cost of making the API slightly more cumbersome to use
> > directly (though again glibc could wrap that away).
>
> I don't see how 3 is cumbersome to use directly. Userspace code does
> struct openat_of_the_day args = {.field1 = x, .field3 = y} and passes
> &args, sizeof(args). What does glibc need to do beyond its usual munging
> of the userspace ABI registers to the syscall ABI registers?
I'd argue that
ret = openat2(AT_FDCWD, "foo", &how, sizeof(how)); // (3)
is slightly less pretty than
ret = openat2(AT_FDCWD, "foo", &how); // (1), (2), (4)
But it's not really that bad. Forget I said anything.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.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 v4, 23/33] drm/mediatek: add ovl0/ovl_2l0 usecase
From: Yongqiang Niu @ 2019-08-29 13:15 UTC (permalink / raw)
To: CK Hu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1563346064.29169.24.camel@mtksdaap41>
On Wed, 2019-07-17 at 14:47 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Tue, 2019-07-09 at 06:34 +0800, yongqiang.niu@mediatek.com wrote:
> > From: Yongqiang Niu <yongqiang.niu@mediatek.com>
> >
> > This patch add ovl0/ovl_2l0 usecase
> > in ovl->ovl_2l0 direct link usecase:
> > 1. the crtc support layer number will 4+2
> > 2. ovl_2l0 background color input select ovl0 when crtc init
> > and disable it when crtc finish
> > 3. config ovl_2l0 layer, if crtc config layer number is
> > bigger than ovl0 support layers(max is 4)
> >
> > Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 38 +++++++++++++++++++++++++++++++--
> > 1 file changed, 36 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > index 5eac376..9ee9ce2 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> > @@ -282,6 +282,15 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> >
> > for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
> > struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
> > + enum mtk_ddp_comp_id prev;
> > +
> > + if (i > 0)
> > + prev = mtk_crtc->ddp_comp[i - 1]->id;
> > + else
> > + prev = DDP_COMPONENT_ID_MAX;
> > +
> > + if (prev == DDP_COMPONENT_OVL0)
> > + mtk_ddp_comp_bgclr_in_on(comp);
>
> I does not like to use a specific component id to check, that is not
> general. For now, you could simply call mtk_ddp_comp_bgclr_in_on(comp);
> for all component because only ovl_2l has implemented it.
>
> Regards,
> CK
>
both OVL0 and OVL_2L0 has the function mtk_ddp_comp_bgclr_in_on
> >
> > mtk_ddp_comp_config(comp, width, height, vrefresh, bpc);
> > mtk_ddp_comp_start(comp);
> > @@ -291,9 +300,18 @@ static int mtk_crtc_ddp_hw_init(struct mtk_drm_crtc *mtk_crtc)
> > for (i = 0; i < mtk_crtc->layer_nr; i++) {
> > struct drm_plane *plane = &mtk_crtc->planes[i];
> > struct mtk_plane_state *plane_state;
> > + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> > + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> > + unsigned int local_layer;
> >
> > plane_state = to_mtk_plane_state(plane->state);
> > - mtk_ddp_comp_layer_config(mtk_crtc->ddp_comp[0], i,
> > +
> > + if (i >= comp_layer_nr) {
> > + comp = mtk_crtc->ddp_comp[1];
> > + local_layer = i - comp_layer_nr;
> > + } else
> > + local_layer = i;
> > + mtk_ddp_comp_layer_config(comp , local_layer,
> > plane_state);
> > }
> >
> > @@ -319,6 +337,7 @@ static void mtk_crtc_ddp_hw_fini(struct mtk_drm_crtc *mtk_crtc)
> > mtk_crtc->ddp_comp[i]->id);
> > mtk_disp_mutex_disable(mtk_crtc->mutex);
> > for (i = 0; i < mtk_crtc->ddp_comp_nr - 1; i++) {
> > + mtk_ddp_comp_bgclr_in_off(mtk_crtc->ddp_comp[i]);
> > mtk_ddp_remove_comp_from_path(mtk_crtc->config_regs,
> > mtk_crtc->mmsys_reg_data,
> > mtk_crtc->ddp_comp[i]->id,
> > @@ -339,6 +358,8 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> > struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
> > struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
> > unsigned int i;
> > + unsigned int comp_layer_nr = mtk_ddp_comp_layer_nr(comp);
> > + unsigned int local_layer;
> >
> > /*
> > * TODO: instead of updating the registers here, we should prepare
> > @@ -361,7 +382,14 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc)
> > plane_state = to_mtk_plane_state(plane->state);
> >
> > if (plane_state->pending.config) {
> > - mtk_ddp_comp_layer_config(comp, i, plane_state);
> > + if (i >= comp_layer_nr) {
> > + comp = mtk_crtc->ddp_comp[1];
> > + local_layer = i - comp_layer_nr;
> > + } else
> > + local_layer = i;
> > +
> > + mtk_ddp_comp_layer_config(comp, local_layer,
> > + plane_state);
> > plane_state->pending.config = false;
> > }
> > }
> > @@ -592,6 +620,12 @@ int mtk_drm_crtc_create(struct drm_device *drm_dev,
> > }
> >
> > mtk_crtc->layer_nr = mtk_ddp_comp_layer_nr(mtk_crtc->ddp_comp[0]);
> > + if (mtk_crtc->ddp_comp_nr > 1) {
> > + struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[1];
> > +
> > + if (comp->funcs->bgclr_in_on)
> > + mtk_crtc->layer_nr += mtk_ddp_comp_layer_nr(comp);
> > + }
> > mtk_crtc->planes = devm_kcalloc(dev, mtk_crtc->layer_nr,
> > sizeof(struct drm_plane),
> > GFP_KERNEL);
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 03/11] soc: ti: omap-prm: poll for reset complete during de-assert
From: Philipp Zabel @ 2019-08-29 13:14 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <20190828071941.32378-4-t-kristo@ti.com>
Hi Tero,
On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
> Poll for reset completion status during de-assertion of reset, otherwise
> the IP in question might be accessed before it has left reset properly.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> drivers/soc/ti/omap_prm.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> index fd5c431f8736..afeb70761b27 100644
> --- a/drivers/soc/ti/omap_prm.c
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -127,6 +127,7 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> u32 v;
> int st_bit;
> bool has_rstst;
> + int timeout = 0;
>
> if (!_is_valid_reset(reset, id))
> return -EINVAL;
> @@ -153,6 +154,25 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> v &= ~(1 << id);
> writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
>
> + if (!has_rstst)
> + return 0;
> +
> + /* wait for the status to be set */
> + while (1) {
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
> + v &= 1 << st_bit;
> + if (v)
> + break;
> + timeout++;
> + if (timeout > OMAP_RESET_MAX_WAIT) {
> + pr_err("%s: timedout waiting for %s:%lu\n", __func__,
> + dev_name(rcdev->dev), id);
> + return -EBUSY;
> + }
> +
> + udelay(1);
> + }
This looks like you could use
readl_relaxed_poll_timeout(_atomic)
regards
Philipp
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCHv2 02/11] soc: ti: add initial PRM driver with reset control support
From: Philipp Zabel @ 2019-08-29 13:12 UTC (permalink / raw)
To: Tero Kristo, ssantosh, linux-arm-kernel, linux-omap, robh+dt
Cc: tony, devicetree
In-Reply-To: <20190828071941.32378-3-t-kristo@ti.com>
On Wed, 2019-08-28 at 10:19 +0300, Tero Kristo wrote:
> Add initial PRM (Power and Reset Management) driver for TI OMAP class
> SoCs. Initially this driver only supports reset control, but can be
> extended to support rest of the functionality, like powerdomain
> control, PRCM irq support etc.
>
> Signed-off-by: Tero Kristo <t-kristo@ti.com>
> ---
> arch/arm/mach-omap2/Kconfig | 1 +
> drivers/soc/ti/Makefile | 1 +
> drivers/soc/ti/omap_prm.c | 235 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 237 insertions(+)
> create mode 100644 drivers/soc/ti/omap_prm.c
>
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index fdb6743760a2..ad08d470a2ca 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -109,6 +109,7 @@ config ARCH_OMAP2PLUS
> select TI_SYSC
> select OMAP_IRQCHIP
> select CLKSRC_TI_32K
> + select ARCH_HAS_RESET_CONTROLLER
> help
> Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
>
> diff --git a/drivers/soc/ti/Makefile b/drivers/soc/ti/Makefile
> index b3868d392d4f..788b5cd1e180 100644
> --- a/drivers/soc/ti/Makefile
> +++ b/drivers/soc/ti/Makefile
> @@ -6,6 +6,7 @@ obj-$(CONFIG_KEYSTONE_NAVIGATOR_QMSS) += knav_qmss.o
> knav_qmss-y := knav_qmss_queue.o knav_qmss_acc.o
> obj-$(CONFIG_KEYSTONE_NAVIGATOR_DMA) += knav_dma.o
> obj-$(CONFIG_AMX3_PM) += pm33xx.o
> +obj-$(CONFIG_ARCH_OMAP2PLUS) += omap_prm.o
> obj-$(CONFIG_WKUP_M3_IPC) += wkup_m3_ipc.o
> obj-$(CONFIG_TI_SCI_PM_DOMAINS) += ti_sci_pm_domains.o
> obj-$(CONFIG_TI_SCI_INTA_MSI_DOMAIN) += ti_sci_inta_msi.o
> diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
> new file mode 100644
> index 000000000000..fd5c431f8736
> --- /dev/null
> +++ b/drivers/soc/ti/omap_prm.c
> @@ -0,0 +1,235 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * OMAP2+ PRM driver
> + *
> + * Copyright (C) 2019 Texas Instruments Incorporated - http://www.ti.com/
> + * Tero Kristo <t-kristo@ti.com>
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
Why <linux/module.h>? This is a builtin driver.
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/platform_device.h>
> +#include <linux/reset-controller.h>
> +#include <linux/delay.h>
> +
> +struct omap_rst_map {
> + s8 rst;
> + s8 st;
> +};
> +
> +struct omap_prm_data {
> + u32 base;
> + const char *name;
> + u16 rstctrl;
> + u16 rstst;
> + const struct omap_rst_map *rstmap;
> + u8 flags;
> +};
I wonder if splitting rstctrl/rstst/rstmap out into a separate structure
would make sense. That could be linked from omap_reset_data directly.
That only makes sense if there'd be enough cases where it can be reused
for multiple PRMs instances.
> +
> +struct omap_prm {
> + const struct omap_prm_data *data;
> + void __iomem *base;
> +};
> +
> +struct omap_reset_data {
> + struct reset_controller_dev rcdev;
> + struct omap_prm *prm;
> +};
> +
> +#define to_omap_reset_data(p) container_of((p), struct omap_reset_data, rcdev)
> +
> +#define OMAP_MAX_RESETS 8
> +#define OMAP_RESET_MAX_WAIT 10000
> +
> +#define OMAP_PRM_HAS_RSTCTRL BIT(0)
> +#define OMAP_PRM_HAS_RSTST BIT(1)
> +
> +#define OMAP_PRM_HAS_RESETS (OMAP_PRM_HAS_RSTCTRL | OMAP_PRM_HAS_RSTST)
> +
> +static const struct of_device_id omap_prm_id_table[] = {
> + { },
> +};
> +
> +static bool _is_valid_reset(struct omap_reset_data *reset, unsigned long id)
> +{
> + const struct omap_rst_map *map = reset->prm->data->rstmap;
> +
> + while (map && map->rst >= 0) {
If rstmap is never NULL,
while (map->rst >= 0) {
should be enough.
> + if (map->rst == id)
> + return true;
> + map++;
> + }
> +
> + return false;
> +}
> +
> +static int omap_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
> + u32 v;
> +
> + if (!_is_valid_reset(reset, id))
> + return -EINVAL;
Don't check this in the status/(de)assert/reset callbacks. Instead,
implement rcdev.of_xlate and return -EINVAL there, so that invalid ids
can never be requested.
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
> + v &= 1 << id;
> + v >>= id;
omap_get_st_bit below makes it look like the status bit can be in a
different place than the reset control bit, should that be used here as
well?
> +
> + return v;
> +}
> +
> +static int omap_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
> + u32 v;
> +
> + if (!_is_valid_reset(reset, id))
> + return -EINVAL;
Same as above.
> + /* assert the reset control line */
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
> + v |= 1 << id;
> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
This read-modify-write should be protected with a lock.
> +
> + return 0;
> +}
> +
> +static int omap_reset_get_st_bit(struct omap_reset_data *reset,
> + unsigned long id)
> +{
> + const struct omap_rst_map *map = reset->prm->data->rstmap;
> +
> + while (map && map->rst >= 0) {
Same as above.
> + if (map->rst == id)
> + return map->st;
> +
> + map++;
> + }
> +
> + return id;
> +}
> +
> +/*
> + * Note that status will not change until clocks are on, and clocks cannot be
> + * enabled until reset is deasserted. Consumer drivers must check status
> + * separately after enabling clocks.
> + */
> +static int omap_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct omap_reset_data *reset = to_omap_reset_data(rcdev);
> + u32 v;
> + int st_bit;
> + bool has_rstst;
> +
> + if (!_is_valid_reset(reset, id))
> + return -EINVAL;
Same as above.
> + /* check the current status to avoid de-asserting the line twice */
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
> + if (!(v & BIT(id)))
> + return -EEXIST;
What is the purpose of this? For shared consumers the core already does
refcounting, and I expect exclusive consumers won't deassert twice.
Since the reset signal is deasserted after this call, this should not
return an error.
> +
> + has_rstst = reset->prm->data->rstst ||
> + (reset->prm->data->flags & OMAP_PRM_HAS_RSTST);
> +
> + if (has_rstst) {
> + st_bit = omap_reset_get_st_bit(reset, id);
> +
> + /* Clear the reset status by writing 1 to the status bit */
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstst);
> + v |= 1 << st_bit;
> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstst);
What does the value read from the rstst register indicate? Is it the
current state of the reset line? Is it 0 until deassertion is completed,
and then it turns to 1?
> + }
> +
> + /* de-assert the reset control line */
> + v = readl_relaxed(reset->prm->base + reset->prm->data->rstctrl);
Reading the register again seems unnecessary.
> + v &= ~(1 << id);
> + writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
As above, the read-modify-write should be locked.
> +
> + return 0;
> +}
> +
> +static const struct reset_control_ops omap_reset_ops = {
> + .assert = omap_reset_assert,
> + .deassert = omap_reset_deassert,
> + .status = omap_reset_status,
> +};
> +
> +static int omap_prm_reset_init(struct platform_device *pdev,
> + struct omap_prm *prm)
> +{
> + struct omap_reset_data *reset;
> +
> + /*
> + * Check if we have controllable resets. If either rstctrl is non-zero
> + * or OMAP_PRM_HAS_RSTCTRL flag is set, we have reset control register
> + * for the domain.
> + */
> + if (!prm->data->rstctrl && !(prm->data->flags & OMAP_PRM_HAS_RSTCTRL))
> + return 0;
> +
> + reset = devm_kzalloc(&pdev->dev, sizeof(*reset), GFP_KERNEL);
> + if (!reset)
> + return -ENOMEM;
> +
> + reset->rcdev.owner = THIS_MODULE;
> + reset->rcdev.ops = &omap_reset_ops;
> + reset->rcdev.of_node = pdev->dev.of_node;
> + reset->rcdev.nr_resets = OMAP_MAX_RESETS;
> +
> + reset->prm = prm;
> +
> + return devm_reset_controller_register(&pdev->dev, &reset->rcdev);
> +}
> +
> +static int omap_prm_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + const struct omap_prm_data *data;
> + struct omap_prm *prm;
> + const struct of_device_id *match;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -ENODEV;
This can be merged with devm_ioremap_resource below.
> + match = of_match_device(omap_prm_id_table, &pdev->dev);
> + if (!match)
> + return -ENOTSUPP;
> +
> + prm = devm_kzalloc(&pdev->dev, sizeof(*prm), GFP_KERNEL);
> + if (!prm)
> + return -ENOMEM;
> +
> + data = match->data;
> +
> + while (data->base != res->start) {
> + if (!data->base)
> + return -EINVAL;
> + data++;
> + }
Is this not something that you want to have encoded in the compatible
string? They all have a different register layout.
> +
> + prm->data = data;
> +
> + prm->base = devm_ioremap_resource(&pdev->dev, res);
prm->base = devm_platform_ioremap_resource(pdev, 0);
> + if (!prm->base)
> + return -ENOMEM;
> +
> + return omap_prm_reset_init(pdev, prm);
> +}
> +
> +static struct platform_driver omap_prm_driver = {
> + .probe = omap_prm_probe,
> + .driver = {
> + .name = KBUILD_MODNAME,
> + .of_match_table = omap_prm_id_table,
> + },
> +};
> +builtin_platform_driver(omap_prm_driver);
regards
Philipp
_______________________________________________
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 v11 7/8] open: openat2(2) syscall
From: Rasmus Villemoes @ 2019-08-29 13:05 UTC (permalink / raw)
To: Aleksa Sarai, Daniel Colascione
Cc: linux-ia64, linux-sh, Alexei Starovoitov, linux-kernel,
David Howells, open list:KERNEL SELFTEST FRAMEWORK, sparclinux,
Shuah Khan, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, David Drysdale, Christian Brauner,
J. Bruce Fields, linux-parisc, Linux API, Chanho Min, Jeff Layton,
Oleg Nesterov, Eric Biederman, linux-alpha, Linux FS Devel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <20190829121527.u2uvdyeatme5cgkb@yavin>
On 29/08/2019 14.15, Aleksa Sarai wrote:
> On 2019-08-24, Daniel Colascione <dancol@google.com> wrote:
>> Why pad the structure when new functionality (perhaps accommodated via
>> a larger structure) could be signaled by passing a new flag? Adding
>> reserved fields to a structure with a size embedded in the ABI makes a
>> lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
>> can grow, so the reservation seems needless to me.
>
> Quite a few folks have said that ->reserved is either unnecessary or
> too big. I will be changing this, though I am not clear what the best
> way of extending the structure is. If anyone has a strong opinion on
> this (or an alternative to the ones listed below), please chime in. I
> don't have any really strong attachment to this aspect of the API.
>
> There appear to be a few ways we can do it (that all have precedence
> with other syscalls):
>
> 1. Use O_* flags to indicate extensions.
> 2. A separate "version" field that is incremented when we change.
> 3. Add a size_t argument to openat2(2).
> 4. Reserve space (as in this patchset).
>
> (My personal preference would be (3), followed closely by (2).)
3, definitely, and instead of having to invent a new scheme for every
new syscall, make that the default pattern by providing a helper
int __copy_abi_struct(void *kernel, size_t ksize, const void __user
*user, size_t usize)
{
size_t copy = min(ksize, usize);
if (copy_from_user(kernel, user, copy))
return -EFAULT;
if (usize > ksize) {
/* maybe a separate "return user_is_zero(user + ksize, usize -
ksize);" helper */
char c;
user += ksize;
usize -= ksize;
while (usize--) {
if (get_user(c, user++))
return -EFAULT;
if (c)
return -EINVAL;
}
} else if (ksize > usize) {
memset(kernel + usize, 0, ksize - usize);
}
return 0;
}
#define copy_abi_struct(kernel, user, usize) \
__copy_abi_struct(kernel, sizeof(*kernel), user, usize)
> Both (1) and (2) have the problem that the "struct version" is inside
> the struct so we'd need to copy_from_user() twice. This isn't the end of
> the world, it just feels a bit less clean than is ideal. (3) fixes that
> problem, at the cost of making the API slightly more cumbersome to use
> directly (though again glibc could wrap that away).
I don't see how 3 is cumbersome to use directly. Userspace code does
struct openat_of_the_day args = {.field1 = x, .field3 = y} and passes
&args, sizeof(args). What does glibc need to do beyond its usual munging
of the userspace ABI registers to the syscall ABI registers?
Rasmus
_______________________________________________
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 v4, 12/33] drm/mediatek: split DISP_REG_CONFIG_DSI_SEL setting into another use case
From: Yongqiang Niu @ 2019-08-29 12:39 UTC (permalink / raw)
To: CK Hu
Cc: Mark Rutland, devicetree, Philipp Zabel, David Airlie,
linux-kernel, dri-devel, Rob Herring, linux-mediatek,
Daniel Vetter, Matthias Brugger, linux-arm-kernel
In-Reply-To: <1563341736.29169.15.camel@mtksdaap41>
On Wed, 2019-07-17 at 13:35 +0800, CK Hu wrote:
> Hi, Yongqiang:
>
> On Tue, 2019-07-09 at 06:33 +0800, yongqiang.niu@mediatek.com wrote:
> > From: Yongqiang Niu <yongqiang.niu@mediatek.com>
> >
> > Here is two modifition in this patch:
> > 1.bls->dpi0 and rdma1->dsi are differen usecase,
> > Split DISP_REG_CONFIG_DSI_SEL setting into anther usecase
> > 2.remove DISP_REG_CONFIG_DPI_SEL setting, DPI_SEL_IN_BLS is 0 and
> > this is same with hardware defautl setting,
> >
>
> You move 2 register setting out of the path from BLS to DPI0, does this
> path still work? Please make sure that all modification could work on
> all supported SoC.
>
> Regards,
> CK
>
DPI_SEL_IN_BLS is 0 and this is same with hardware default setting as
description in patch.
the removed sentence is useless.
> > Signed-off-by: Yongqiang Niu <yongqiang.niu@mediatek.com>
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > index d015c1a..47b3e35 100644
> > --- a/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > +++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp.c
> > @@ -400,10 +400,9 @@ static void mtk_ddp_sout_sel(void __iomem *config_regs,
> > } else if (cur == DDP_COMPONENT_BLS && next == DDP_COMPONENT_DPI0) {
> > writel_relaxed(BLS_TO_DPI_RDMA1_TO_DSI,
> > config_regs + DISP_REG_CONFIG_OUT_SEL);
> > + } else if (cur == DDP_COMPONENT_RDMA1 && next == DDP_COMPONENT_DSI0) {
> > writel_relaxed(DSI_SEL_IN_RDMA,
> > config_regs + DISP_REG_CONFIG_DSI_SEL);
> > - writel_relaxed(DPI_SEL_IN_BLS,
> > - config_regs + DISP_REG_CONFIG_DPI_SEL);
> > }
> > }
> >
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 00/14] Improvements and fixes for mxsfb DRM driver
From: Robert Chiras @ 2019-08-29 11:30 UTC (permalink / raw)
To: Guido Günther, Marek Vasut, Stefan Agner, David Airlie,
Daniel Vetter, Rob Herring, Mark Rutland, Shawn Guo, Sascha Hauer,
Fabio Estevam
Cc: devicetree, linux-kernel, dri-devel, NXP Linux Team,
Pengutronix Kernel Team, linux-arm-kernel
This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
and 8QXP). Following, are the new features added and fixes from this
patch-set:
1. Add support for drm_bridge
On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
display connector, where an LCD panel can be attached, but instead it is
connected to DSI controller. Since this DSI stands between the display
controller (eLCDIF) and the physical connector, the DSI can be implemented
as a DRM bridge. So, in order to be able to connect the mxsfb driver to
the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
driver (the actual driver for the eLCDIF block).
2. Add support for additional pixel formats
Some of the pixel formats needed by Android were not implemented in this
driver, but they were actually supported. So, add support for them.
3. Add support for horizontal stride
Having support for horizontal stride allows the use of eLCDIF with a GPU
(for example) that can only output resolution sizes multiple of a power of
8. For example, 1080 is not a power of 16, so in order to support 1920x1080
output from GPUs that can produce linear buffers only in sizes multiple to 16,
this feature is needed.
3. Few minor features and bug-fixing
The addition of max-memory-bandwidth DT property was actually needed in order
to limit the bandwidth usage of the eLCDIF block. This is need on systems where
multiple display controllers are presend and the memory bandwidth is not
enough to handle all of them at maximum capacity (like it is the case on
8MQ, where there are two display controllers: DCSS and eLCDIF).
The rest of the patches are bug-fixes.
v4:
- Removed the "Fix vblank events" patch (will cover this issue later, on a
separate thread)
- Colleted "Tested-by" from Guido
- Collected "Reviewed-by" from Rob Herring
v3:
- Removed the max-res property patches and added support for
max-memory-bandwidth property, as it is also implemented in other drivers
- Removed unnecessary drm_vblank_off in probe
v2:
- Collected Tested-by from Guido
- Split the first patch, which added more than one feature into relevant
patches, explaining each feature added
- Also split the second patch into more patches, to differentiate between
the feature itself (additional pixel formats support) and the cleanup
of the register definitions for a better representation (guido)
- Included a patch submitted by Guido, while he was testing my patch-set
Guido Günther (1):
drm/mxsfb: Read bus flags from bridge if present
Mirela Rabulea (1):
drm/mxsfb: Signal mode changed when bpp changed
Robert Chiras (12):
drm/mxsfb: Update mxsfb to support a bridge
drm/mxsfb: Add defines for the rest of registers
drm/mxsfb: Reset vital registers for a proper initialization
drm/mxsfb: Update register definitions using bit manipulation defines
drm/mxsfb: Update mxsfb with additional pixel formats
drm/mxsfb: Add max-memory-bandwidth property for MXSFB
dt-bindings: display: Add max-memory-bandwidth property for mxsfb
drm/mxsfb: Update mxsfb to support LCD reset
drm/mxsfb: Improve the axi clock usage
drm/mxsfb: Clear OUTSTANDING_REQS bits
drm/mxsfb: Add support for horizontal stride
drm/mxsfb: Add support for live pixel format change
.../devicetree/bindings/display/mxsfb.txt | 5 +
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 194 ++++++++++++--
drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
6 files changed, 581 insertions(+), 136 deletions(-)
--
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 v3 2/3] dt-bindings: arm: amlogic: add Amlogic SM1 based Khadas VIM3L bindings
From: Rob Herring @ 2019-08-29 12:26 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, linux-amlogic, linux-kernel, linux-arm-kernel,
devicetree
In-Reply-To: <20190828141816.16328-3-narmstrong@baylibre.com>
On Wed, Aug 28, 2019 at 04:18:15PM +0200, Neil Armstrong wrote:
> The Khadas VIM3 is also available as VIM3L with the Pin-to-pin compatible
> Amlogic SM1 SoC in the S905D3 variant package.
>
> Change the description to match the S905X3/D3/Y3 variants like the G12A
> description, and add the khadas,vim3l compatible.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> Documentation/devicetree/bindings/arm/amlogic.yaml | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Reviewed-by: Rob Herring <robh@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 5/7] arm64: compat: vdso: Remove unused VDSO_HAS_32BIT_FALLBACK
From: Thomas Gleixner @ 2019-08-29 12:21 UTC (permalink / raw)
To: Vincenzo Frascino
Cc: linux-arch, catalin.marinas, 0x7f454c46, linux-kernel, linux-mips,
paul.burton, luto, salyzyn, will, linux-arm-kernel
In-Reply-To: <20190829111843.41003-6-vincenzo.frascino@arm.com>
On Thu, 29 Aug 2019, Vincenzo Frascino wrote:
> As a consequence of Commit 623fa33f7bd6 ("lib:vdso: Remove
-ENOSUCH commit ....
Just say:
VDSO_HAS_32BIT_FALLBACK has been removed from the core ....
Thanks,
tglx
_______________________________________________
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 v11 7/8] open: openat2(2) syscall
From: Aleksa Sarai @ 2019-08-29 12:15 UTC (permalink / raw)
To: Daniel Colascione
Cc: linux-ia64, linux-sh, Alexei Starovoitov, linux-kernel,
David Howells, open list:KERNEL SELFTEST FRAMEWORK, sparclinux,
Shuah Khan, linux-arch, linux-s390, Tycho Andersen, Aleksa Sarai,
linux-arm-kernel, linux-mips, linux-xtensa, Kees Cook,
Arnd Bergmann, Jann Horn, linuxppc-dev, linux-m68k, Al Viro,
Andy Lutomirski, Shuah Khan, David Drysdale, Christian Brauner,
J. Bruce Fields, linux-parisc, Linux API, Chanho Min, Jeff Layton,
Oleg Nesterov, Eric Biederman, linux-alpha, Linux FS Devel,
Andrew Morton, Linus Torvalds, containers
In-Reply-To: <CAKOZuesfxRBJe314rkTKXtjXdz6ki3uAUBYVbu5Q2rd3=ADphQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4616 bytes --]
On 2019-08-24, Daniel Colascione <dancol@google.com> wrote:
> On Mon, Aug 19, 2019 at 8:37 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> >
> > The most obvious syscall to add support for the new LOOKUP_* scoping
> > flags would be openat(2). However, there are a few reasons why this is
> > not the best course of action:
> >
> > * The new LOOKUP_* flags are intended to be security features, and
> > openat(2) will silently ignore all unknown flags. This means that
> > users would need to avoid foot-gunning themselves constantly when
> > using this interface if it were part of openat(2). This can be fixed
> > by having userspace libraries handle this for users[1], but should be
> > avoided if possible.
> >
> > * Resolution scoping feels like a different operation to the existing
> > O_* flags. And since openat(2) has limited flag space, it seems to be
> > quite wasteful to clutter it with 5 flags that are all
> > resolution-related. Arguably O_NOFOLLOW is also a resolution flag but
> > its entire purpose is to error out if you encounter a trailing
> > symlink -- not to scope resolution.
> >
> > * Other systems would be able to reimplement this syscall allowing for
> > cross-OS standardisation rather than being hidden amongst O_* flags
> > which may result in it not being used by all the parties that might
> > want to use it (file servers, web servers, container runtimes, etc).
> >
> > * It gives us the opportunity to iterate on the O_PATH interface. In
> > particular, the new @how->upgrade_mask field for fd re-opening is
> > only possible because we have a clean slate without needing to re-use
> > the ACC_MODE flag design nor the existing openat(2) @mode semantics.
> >
> > To this end, we introduce the openat2(2) syscall. It provides all of the
> > features of openat(2) through the @how->flags argument, but also
> > also provides a new @how->resolve argument which exposes RESOLVE_* flags
> > that map to our new LOOKUP_* flags. It also eliminates the long-standing
> > ugliness of variadic-open(2) by embedding it in a struct.
> >
> > In order to allow for userspace to lock down their usage of file
> > descriptor re-opening, openat2(2) has the ability for users to disallow
> > certain re-opening modes through @how->upgrade_mask. At the moment,
> > there is no UPGRADE_NOEXEC. The open_how struct is padded to 64 bytes
> > for future extensions (all of the reserved bits must be zeroed).
>
> Why pad the structure when new functionality (perhaps accommodated via
> a larger structure) could be signaled by passing a new flag? Adding
> reserved fields to a structure with a size embedded in the ABI makes a
> lot of sense --- e.g., pthread_mutex_t can't grow. But this structure
> can grow, so the reservation seems needless to me.
Quite a few folks have said that ->reserved is either unnecessary or
too big. I will be changing this, though I am not clear what the best
way of extending the structure is. If anyone has a strong opinion on
this (or an alternative to the ones listed below), please chime in. I
don't have any really strong attachment to this aspect of the API.
There appear to be a few ways we can do it (that all have precedence
with other syscalls):
1. Use O_* flags to indicate extensions.
2. A separate "version" field that is incremented when we change.
3. Add a size_t argument to openat2(2).
4. Reserve space (as in this patchset).
(My personal preference would be (3), followed closely by (2).)
The main problem with (1) is that it pollutes the open(2) and openat(2)
syscalls with new O_* flags, which is probably not a good API decision
(syscall flags are already "bad" enough, let's not throw a bunch of
no-ops into the mix).
(2) is mostly fine except for a slight issue of ergonomics (glibc would
have to auto-fill the version field or make wrappers in order to make it
easier to use sanely). But this does have the benefit that we could
re-arrange fields (not that this is something we'd want to do anyway).
Both (1) and (2) have the problem that the "struct version" is inside
the struct so we'd need to copy_from_user() twice. This isn't the end of
the world, it just feels a bit less clean than is ideal. (3) fixes that
problem, at the cost of making the API slightly more cumbersome to use
directly (though again glibc could wrap that away).
And the downsides of (4) are pretty well discussed already.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.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 2/6] dt-bindings: PCI: tegra: Add PCIe slot supplies regulator entries
From: Thierry Reding @ 2019-08-29 12:03 UTC (permalink / raw)
To: Vidya Sagar
Cc: devicetree, lorenzo.pieralisi, mperttunen, mmaddireddy, kthota,
gustavo.pimentel, linux-kernel, kishon, linux-tegra, robh+dt,
linux-pci, bhelgaas, andrew.murray, digetx, jonathanh,
linux-arm-kernel, sagar.tv
In-Reply-To: <20190828172850.19871-3-vidyas@nvidia.com>
[-- Attachment #1.1: Type: text/plain, Size: 3136 bytes --]
On Wed, Aug 28, 2019 at 10:58:46PM +0530, Vidya Sagar wrote:
> Add optional bindings "vpcie3v3-supply" and "vpcie12v-supply" to describe
> regulators of a PCIe slot's supplies 3.3V and 12V provided the platform
> is designed to have regulator controlled slot supplies.
>
> Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
> ---
> V3:
> * None
>
> V2:
> * None
>
> .../devicetree/bindings/pci/nvidia,tegra194-pcie.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
> index 0ac1b867ac24..b739f92da58e 100644
> --- a/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
> +++ b/Documentation/devicetree/bindings/pci/nvidia,tegra194-pcie.txt
> @@ -104,6 +104,12 @@ Optional properties:
> specified in microseconds
> - nvidia,aspm-l0s-entrance-latency-us: ASPM L0s entrance latency to be
> specified in microseconds
> +- vpcie3v3-supply: A phandle to the regulator node that supplies 3.3V to the slot
> + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
> + in p2972-0000 platform).
> +- vpcie12v-supply: A phandle to the regulator node that supplies 12V to the slot
> + if the platform has one such slot. (Ex:- x16 slot owned by C5 controller
> + in p2972-0000 platform).
There's an ongoing discussion regarding the use of optional power
supplies and I'm wondering if we're not abusing this here. Why exactly
are these regulators optional?
The distinction is somewhat subtle, but the other way to look at
modelling this in DT is that the supplies are in fact required, but may
be connected to an always-on regulator with a fixed voltage. Or in some
cases they may also be shorted to ground. In both cases the PCI
controller, or rather the slot that the controller connects to, actually
"requires" the supplies, it's just that we can get away without
describing them because they can't be controlled anyway.
Looking at the PCI connector pinout for PCI Express, I do see a bunch of
+3.3 V and +12 V pins. To me that indicates that the 3.3 V and 12 V
supplies are indeed required for PCI slots. I'm not sure about devices
that are directly connected to the PCI controller, though. I'll need to
go look at some schematics to get a better understanding of these.
Bottom line: I'm wondering if we shouldn't really make these supplies
mandatory and in case where we don't care either just leave them away
(the regulator framework will supply a dummy regulator in that case) or
hook them up to a fixed regulator if that matches the hardware design.
Any thoughts?
Thierry
>
> Examples:
> =========
> @@ -156,6 +162,8 @@ Tegra194:
> 0xc2000000 0x18 0x00000000 0x18 0x00000000 0x4 0x00000000>; /* prefetchable memory (16GB) */
>
> vddio-pex-ctl-supply = <&vdd_1v8ao>;
> + vpcie3v3-supply = <&vdd_3v3_pcie>;
> + vpcie12v-supply = <&vdd_12v_pcie>;
>
> phys = <&p2u_hsio_2>, <&p2u_hsio_3>, <&p2u_hsio_4>,
> <&p2u_hsio_5>;
> --
> 2.17.1
>
[-- 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 v2 1/2] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Marco Felsch @ 2019-08-29 11:50 UTC (permalink / raw)
To: Robin Gong
Cc: Mark Rutland, devicetree @ vger . kernel . org, Fabio Estevam,
robin, Sascha Hauer, Dmitry Torokhov,
linux-kernel @ vger . kernel . org, Rob Herring, dl-linux-imx,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <VE1PR04MB6638A54664EE3FFE16BD419189A20@VE1PR04MB6638.eurprd04.prod.outlook.com>
On 19-08-29 09:11, Robin Gong wrote:
>
> On 2019-08-29 16:17, Marco Felsch wrote:
> > > > While reading the rm it seems that
> > > > the snvs block has a dedicated version register. IMHO this could be
> > > > a better way to apply the change also to existing devices with old
> > > > firmware.
> > >
> > > I thought the same thing, and fully agree with you. However I do not
> > > have a way to determine which versions are out there. Since I couldn't
> > > find any documentation on this, and I only have i.MX6 S/DL, D/Q and UL
> > laying around.
> >
> > @NXP Kernel Team
> > Can we get some more information here?
> Go ahead, please. That snvs version register SNVS_HPVIDR1 should work as expect.
> MINOR_REV checking is enough, none-zero means for soc after i.mx6sx, but
> Zero means i.mx6q/dl/sl elder soc.
Thanks. Robin can you integrate that so we can drop the different
dt-handling?
Regards,
Marco
> >
> > Regards,
> > Marco
> >
> > > Regards,
> > > Robin van der Gracht
> > >
> >
> > --
> > Pengutronix e.K. |
> > |
> > Industrial Linux Solutions |
> > https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.p
> > engutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7C8d4e1
> > 0cd77bd4652f3eb08d72c594e76%7C686ea1d3bc2b4c6fa92cd99c5c301635%7
> > C0%7C0%7C637026634390359345&sdata=mhXlUxmLWg8qtwhPQfkJZm
> > VAn4QQ3YybLOSh83uf27E%3D&reserved=0 |
> > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> > |
> > Amtsgericht Hildesheim, HRA 2686 | Fax:
> > +49-5121-206917-5555 |
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
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 04/11] kselftest: arm64: mangle_pstate_invalid_mode_el
From: Cristian Marussi @ 2019-08-29 11:50 UTC (permalink / raw)
To: Dave Martin; +Cc: andreyknvl, shuah, linux-arm-kernel, linux-kselftest
In-Reply-To: <20190813162451.GB10425@arm.com>
On 13/08/2019 17:24, Dave Martin wrote:
> On Fri, Aug 02, 2019 at 06:02:53PM +0100, Cristian Marussi wrote:
>> Added 3 simple mangle testcases that mess with the ucontext_t
>
> Add
>
>> from within the sig_handler, trying to toggle PSTATE mode bits to
>
> signal handler
>
>> trick the system into switching to EL1/EL2/EL3. Expects SIGSEGV
>> on test PASS.
Ok
>>
>> Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
>> ---
>> .../arm64/signal/testcases/.gitignore | 3 ++
>> .../mangle_pstate_invalid_mode_el1.c | 29 +++++++++++++++++++
>> .../mangle_pstate_invalid_mode_el2.c | 29 +++++++++++++++++++
>> .../mangle_pstate_invalid_mode_el3.c | 29 +++++++++++++++++++
>> 4 files changed, 90 insertions(+)
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el1.c
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el2.c
>> create mode 100644 tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el3.c
>>
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/.gitignore b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> index 8a0a29f0cc2a..226bb179b673 100644
>> --- a/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> +++ b/tools/testing/selftests/arm64/signal/testcases/.gitignore
>> @@ -1,2 +1,5 @@
>> mangle_pstate_invalid_compat_toggle
>> mangle_pstate_invalid_daif_bits
>> +mangle_pstate_invalid_mode_el1
>> +mangle_pstate_invalid_mode_el2
>> +mangle_pstate_invalid_mode_el3
>
> What about having
>
> !*.[ch]
> mangle_*
>
> rather than having to update .gitignore to list every test executable?
>
Yes it reduces inter-dependencies between testcases patches in fact,
and in fact I already know all the possible name patterns on this set of tests:
mangle_ fake_sigreturn_
>> diff --git a/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el1.c b/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el1.c
>> new file mode 100644
>> index 000000000000..07aed7624383
>> --- /dev/null
>> +++ b/tools/testing/selftests/arm64/signal/testcases/mangle_pstate_invalid_mode_el1.c
>> @@ -0,0 +1,29 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/* Copyright (C) 2019 ARM Limited */
>> +
>> +#include "test_signals_utils.h"
>> +#include "testcases.h"
>> +
>> +static int mangle_invalid_pstate_run(struct tdescr *td, siginfo_t *si,
>> + ucontext_t *uc)
>> +{
>> + ASSERT_GOOD_CONTEXT(uc);
>> +
>> + /*
>> + * This config should trigger a SIGSEGV by Kernel
>> + * when checking valid_user_regs()
>> + */
>> + uc->uc_mcontext.pstate &= ~PSR_MODE_MASK;
>> + uc->uc_mcontext.pstate |= PSR_MODE_EL1t;
>> +
>> + return 1;
>> +}
>> +
>> +struct tdescr tde = {
>> + .sanity_disabled = true,
>> + .name = "MANGLE_PSTATE_INVALID_MODE_EL1t",
>> + .descr = "Mangling uc_mcontext with INVALID MODE EL1t",
>> + .sig_trig = SIGUSR1,
>> + .sig_ok = SIGSEGV,
>> + .run = mangle_invalid_pstate_run,
>> +};
>
> These tests seem identical except for the EL number.
> Can we macro-ise them?
>
> mangle_pstate_invalid_mode_el1.c could become
>
> --8<--
>
> #include "mangle_pstate_invalid_mode.h"
>
> DEFINE_TESTCASE_MANGLE_PSTATE_INVALID_MODE(1)
>
> -->8--
Yes I'll do, and I'll split these 3 testcases in 6 macro-ized test cases to cover
all EL_x h/t variants (something you already told me in V2 I think)
Cheers
Cristian
>
> (for example).
>
> [...]
>
> Cheers
> ---Dave
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/2] dma-contiguous: Use fallback alloc_pages for single pages
From: Masahiro Yamada @ 2019-08-29 11:45 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Ulf Hansson, Tony Lindgren, Catalin Marinas, Will Deacon,
Linux Kernel Mailing List, Max Filippov, Marek Szyprowski,
Stephen Rothwell, Joerg Roedel, Russell King, Thierry Reding,
linux-xtensa, Kees Cook, Nicolin Chen, Andrew Morton,
linux-arm-kernel, Chris Zankel, Wolfram Sang, David Woodhouse,
linux-mmc, Adrian Hunter, iommu, iamjoonsoo.kim, Robin Murphy
In-Reply-To: <CAK7LNATvz=TTe+3OyLrtUqDuTUTn1dg9Sk-t3BD_OFZfViCPMw@mail.gmail.com>
On Wed, Aug 28, 2019 at 9:23 PM Masahiro Yamada
<yamada.masahiro@socionext.com> wrote:
>
> On Wed, Aug 28, 2019 at 7:53 PM Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
> >
> > Hi Christoph,
> >
> > On Tue, Aug 27, 2019 at 8:55 PM Christoph Hellwig <hch@lst.de> wrote:
> > >
> > > On Tue, Aug 27, 2019 at 06:03:14PM +0900, Masahiro Yamada wrote:
> > > > Yes, this makes my driver working again
> > > > when CONFIG_DMA_CMA=y.
> > > >
> > > >
> > > > If I apply the following, my driver gets back working
> > > > irrespective of CONFIG_DMA_CMA.
> > >
> > > That sounds a lot like the device simply isn't 64-bit DMA capable, and
> > > previously always got CMA allocations under the limit it actually
> > > supported. I suggest that you submit this quirk to the mmc maintainers.
> >
> >
> > I tested v5.2 and my MMC host controller works with
> > dma_address that exceeds 32-bit physical address.
> >
> > So, I believe my MMC device is 64-bit DMA capable.
> >
> > I am still looking into the code
> > to find out what was changed.
>
>
> I retract this comment.
>
> Prior to bd2e75633c8012fc8a7431c82fda66237133bf7e,
> the descriptor table for ADMA is placed within the
> 32-bit phys address range, not exceeds the 32-bit limit.
>
> Probably, my device is not 64-bit capable.
>
> I will talk to the hardware engineer,
> and check the hardware spec just in case.
>
After looking more into my hardware,
I found out how to fix my driver:
https://lore.kernel.org/patchwork/patch/1121600/
--
Best Regards
Masahiro Yamada
_______________________________________________
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 ARM32 v4.4 V2 00/47] V4.4 backport of arm32 Spectre patches
From: Viresh Kumar @ 2019-08-29 11:40 UTC (permalink / raw)
To: stable
Cc: Mark Rutland, Julien Thierry, Marc Zyngier, Catalin Marinas,
Will Deacon, mark.brown, guohanjun, Russell King,
linux-arm-kernel
In-Reply-To: <cover.1564646727.git.viresh.kumar@linaro.org>
On 01-08-19, 13:45, Viresh Kumar wrote:
> Hello,
>
> Here is an attempt to backport arm32 spectre patches to v4.4 stable
> tree. This was last tried around an year back by David Long [1]. He was
> backporting only a subset (18) of patches and this series include a lot
> of other patches present in Russell's spectre branch.
It's been almost 4 weeks since the first post on this. Can someone
please help with reviews ?
thanks.
--
viresh
_______________________________________________
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] mmc: sunxi: fix unusuable eMMC on some H6 boards by disabling DDR
From: Ulf Hansson @ 2019-08-29 11:37 UTC (permalink / raw)
To: Alejandro González
Cc: Maxime Ripard, Greg Kroah-Hartman, Linus Walleij, linux-sunxi,
linux-mmc@vger.kernel.org, Linux Kernel Mailing List,
Chen-Yu Tsai, Thomas Gleixner, Linux ARM
In-Reply-To: <f84d62b7-da00-f2bd-36e9-972435080bfe@gmail.com>
On Wed, 28 Aug 2019 at 12:52, Alejandro González
<alejandro.gonzalez.correo@gmail.com> wrote:
>
> El 27/8/19 a las 15:24, Ulf Hansson escribió:> Assuming this should go stable as well? Perhaps you can find a
> > relevant commit that we can put as a fixes tag as well?
> >
> > Kind regards
> > Uffe
>
> The most relevant commit I've found that is related to enabling DDR speeds
> on H6 boards is this one: https://github.com/torvalds/linux/commit/07bafc1e3536a4e3c422dbd13341688b54f159bb .
> But it doesn't address the H6 SoC specifically, so I doubted whether it would
> be appropiate to mark this patch as fixing it, and opted to not do it. I don't
> mind adding that tag if it's appropiate, though :-)
Hard to say what makes sense here, but how about picking this below instead?
Fixes: 0a23f1ad88fc ("dt-binding: mmc: sunxi: add H6 compatible (with
A64 fallback)")
>
> On the other hand, I'm not sure that I understood correctly what do you mean by
> this patch going stable, but I might say the changes themselves are stable and work.
> The only downside I can think of to them is that they are a kind of workaround that
> reduces performance on H6 boards and/or eMMC not affected by this problem (are there
> any?), unless device trees are changed.
Adding a stable tag and a fixes tag for the commit, makes maintainers
of stable kernels to try to backport this commit and fix the problem
for "older" kernels.
Kind regards
Uffe
_______________________________________________
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