* [PATCH AUTOSEL 4.14 1/8] ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
From: Sasha Levin @ 2020-06-05 12:26 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Russell King, Fredrik Strupe, Oleg Nesterov,
linux-arm-kernel
From: Fredrik Strupe <fredrik@strupe.net>
[ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ]
call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
(0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
instructions will be masked out. This makes the function match 32-bit
thumb instructions where the second half-word is equal to instr_val,
regardless of the first half-word.
The result in this case is that all undefined 32-bit thumb instructions
with the second half-word equal to 0xde01 (udf #1) work as breakpoints
and will raise a SIGTRAP instead of a SIGILL, instead of just the one
intended 16-bit instruction. An example of such an instruction is
0xeaa0de01, which is unallocated according to Arm ARM and should raise a
SIGILL, but instead raises a SIGTRAP.
This patch fixes the issue by setting all the bits in instr_mask, which
will still match the intended 16-bit thumb instruction (where the
upper half is always 0), but not any 32-bit thumb instructions.
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index 58e3771e4c5b..368b4b404985 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -228,8 +228,8 @@ static struct undef_hook arm_break_hook = {
};
static struct undef_hook thumb_break_hook = {
- .instr_mask = 0xffff,
- .instr_val = 0xde01,
+ .instr_mask = 0xffffffff,
+ .instr_val = 0x0000de01,
.cpsr_mask = PSR_T_BIT,
.cpsr_val = PSR_T_BIT,
.fn = break_trap,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH AUTOSEL 4.9 1/6] ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
From: Sasha Levin @ 2020-06-05 12:26 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Russell King, Fredrik Strupe, Oleg Nesterov,
linux-arm-kernel
From: Fredrik Strupe <fredrik@strupe.net>
[ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ]
call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
(0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
instructions will be masked out. This makes the function match 32-bit
thumb instructions where the second half-word is equal to instr_val,
regardless of the first half-word.
The result in this case is that all undefined 32-bit thumb instructions
with the second half-word equal to 0xde01 (udf #1) work as breakpoints
and will raise a SIGTRAP instead of a SIGILL, instead of just the one
intended 16-bit instruction. An example of such an instruction is
0xeaa0de01, which is unallocated according to Arm ARM and should raise a
SIGILL, but instead raises a SIGTRAP.
This patch fixes the issue by setting all the bits in instr_mask, which
will still match the intended 16-bit thumb instruction (where the
upper half is always 0), but not any 32-bit thumb instructions.
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index ae738a6319f6..364985c96a92 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -227,8 +227,8 @@ static struct undef_hook arm_break_hook = {
};
static struct undef_hook thumb_break_hook = {
- .instr_mask = 0xffff,
- .instr_val = 0xde01,
+ .instr_mask = 0xffffffff,
+ .instr_val = 0x0000de01,
.cpsr_mask = PSR_T_BIT,
.cpsr_val = PSR_T_BIT,
.fn = break_trap,
--
2.25.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH AUTOSEL 4.4 1/3] ARM: 8977/1: ptrace: Fix mask for thumb breakpoint hook
From: Sasha Levin @ 2020-06-05 12:26 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Sasha Levin, Russell King, Fredrik Strupe, Oleg Nesterov,
linux-arm-kernel
From: Fredrik Strupe <fredrik@strupe.net>
[ Upstream commit 3866f217aaa81bf7165c7f27362eee5d7919c496 ]
call_undef_hook() in traps.c applies the same instr_mask for both 16-bit
and 32-bit thumb instructions. If instr_mask then is only 16 bits wide
(0xffff as opposed to 0xffffffff), the first half-word of 32-bit thumb
instructions will be masked out. This makes the function match 32-bit
thumb instructions where the second half-word is equal to instr_val,
regardless of the first half-word.
The result in this case is that all undefined 32-bit thumb instructions
with the second half-word equal to 0xde01 (udf #1) work as breakpoints
and will raise a SIGTRAP instead of a SIGILL, instead of just the one
intended 16-bit instruction. An example of such an instruction is
0xeaa0de01, which is unallocated according to Arm ARM and should raise a
SIGILL, but instead raises a SIGTRAP.
This patch fixes the issue by setting all the bits in instr_mask, which
will still match the intended 16-bit thumb instruction (where the
upper half is always 0), but not any 32-bit thumb instructions.
Cc: Oleg Nesterov <oleg@redhat.com>
Signed-off-by: Fredrik Strupe <fredrik@strupe.net>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
arch/arm/kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/ptrace.c b/arch/arm/kernel/ptrace.c
index d54c53b7ab63..711d854ea13a 100644
--- a/arch/arm/kernel/ptrace.c
+++ b/arch/arm/kernel/ptrace.c
@@ -227,8 +227,8 @@ static struct undef_hook arm_break_hook = {
};
static struct undef_hook thumb_break_hook = {
- .instr_mask = 0xffff,
- .instr_val = 0xde01,
+ .instr_mask = 0xffffffff,
+ .instr_val = 0x0000de01,
.cpsr_mask = PSR_T_BIT,
.cpsr_val = PSR_T_BIT,
.fn = break_trap,
--
2.25.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: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.
From: Will Deacon @ 2020-06-05 12:33 UTC (permalink / raw)
To: Mark Brown
Cc: fujun (F), Wuxuecheng, linux-arm-kernel@lists.infradead.org,
Lixin (Victor, Kirin)
In-Reply-To: <20200605121029.GE5413@sirena.org.uk>
On Fri, Jun 05, 2020 at 01:10:29PM +0100, Mark Brown wrote:
> On Mon, Jun 01, 2020 at 08:03:12AM +0100, Will Deacon wrote:
> > On Fri, May 29, 2020 at 09:03:37AM +0000, Lixin (Victor, Kirin) wrote:
>
> > > Intel optimized getcpu syscall on Linux/Android system by using vDSO, but
> > > ARM doesn't do any optimizations for getcpu syscall.
>
> > > In Apple open source, TPIDRRO_EL0/TPIDRURO is used to save the CPU number,
> > > [1]https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/arm/cswitch.s.auto.html
>
> > > Is there any risk if using TPIDRRO_EL0/TPIDRURO to implement
> > > the vDSO for getcpu? Is there any possible to break any ARM ABI? Can you
> > > help us to confirm the considerations?
>
> > Do you have a use-case for high-performance getcpu() that isn't better
> > suited to rseq()?
>
> I actually have an implementation of this that I'd been waiting for the
> end of the merge window to post, largely because I first heard of the
> use of restartable sequences for this after I'd already implemented the
> vDSO version - this stuff is not as discoverable as one might desire.
> It doesn't store the CPU ID directly in TPIDRRO but rather uses TPIDDRRO
> to store the offset of a per-CPU struct in the vDSO data in order to
> allow for the addition of further data in the future. I'll post it
> today for discussion.
>
> The latest version of the Mathieu's glibc integration patches is:
>
> https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficios.com/
>
> The only things I can see where the vDSO does better are support for the
> node parameter of getcpu() and the ease of implementation for the users,
> the restartable sequences code was merged all the way back in v4.18 and
> it's still not used by any of the libcs as far as I can see. The node
> to CPU mapping is static so I'm not sure how exciting that is, it could
> be looked up separately when processing data if it's important, but the
> ease of use feels like something.
>
> One important caveat with using TPIDRRO is that if KPTI is active then
> the KPTI trampoline uses TPIDRRO as a scratch register so unless we can
> find another register for scratch usage the user would need to give up
> the protections offered by KPTI or run on future hardware which can use
> E0PD instead. This severely limits the usefulness on current systems.
We only trash TPIDRRO on entry, so I think you could repopulate it on every
exception from userspace and it *should* work with KPTI (famous last words!)
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] efi/arm: decompressor: deal with HYP mode boot gracefully
From: Ard Biesheuvel @ 2020-06-05 12:39 UTC (permalink / raw)
To: Heinrich Schuchardt; +Cc: Marc Zyngier, linux-efi, Russell King, Linux ARM
In-Reply-To: <4498d910-f5cb-8559-afba-34710e9ca730@gmx.de>
On Fri, 5 Jun 2020 at 14:20, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:
>
> On 05.06.20 13:52, Ard Biesheuvel wrote:
> > EFI on ARM only supports short descriptors, and given that it mandates
> > that the MMU and caches are on, it is implied that booting in HYP mode
> > is not supported.
> >
> > However, implementations of EFI exist (i.e., U-Boot) that ignore this
> > requirement, which is not entirely unreasonable, given that it does
> > not make a lot of sense to begin with.
>
> Hello Ard,
>
> thanks for investigating the differences between EDK2 and U-Boot.
>
> What I still do not understand is if there is a bug in U-Boot where
> U-Boot does not conform to the UEFI specification? In this case I would
> expect a fix in U-Boot.
>
U-Boot violates the EFI spec, yes. The spec is very clear on how the
MMU is configured, and this rules out booting with the caches off, or
booting in HYP mode.
However, given that this is the situation today, we still need to deal
with it on the Linux side.
In parallel, fixing it in U-boot may be appropriate. However, I think
the EFI spec is too detailed here - instead of 'booting at the highest
non-secure privilege mode', it tells you which exact bits to set in
SCTLR, which seems overzealous to me. In other words, even though it
violates the letter of the spec, I don't mind dealing with this
exception in the Linux side, since the requirement is somewhat
unreasonable to begin with.
> Or is it simply a deficiency of Linux that it does not properly support
> HYP/EL2 mode on 32-bit ARM?
>
No, this is definitely not the fault of Linux.
> Up to now I never experience a problem booting a 32bit board via U-Boot
> -> GRUB-EFI -> Linux. Where did you have a problem when booting via
> U-Boot's UEFI implementation and the current Linux kernel?
>
I haven't managed to make it fail, but my only 32-bit HYP capable
platform is QEMU. I am not 100% convinced that the EFI+HYP+U-Boot case
is rock solid, and I may have gotten lucky with QEMU (which uses
emulation not virtualization when running at HYP)
Do you have any A7/A15 based boards that don't print 'WARNING: Caches
not enabled' at boot?
> Does this patch relate to the retirement of KVM on 32 ARM in Linux 5.7
> 541ad0150ca4 ("arm: Remove 32bit KVM host support")? Without that patch
> I would have expected Linux to work fine in HYP mode.
>
Not really. The code still has to deal with booting at HYP mode,
regardless of whether it is used in a useful way.
I suppose simply dropping to SVC in the decompressor might make sense
as well, given that booting the kernel at HYP doesn't buy you anything
anymore in the first place. Marc may have some thoughts on that, but
it is really a separate discussion.
>
> >
> > So let's make sure that we can deal with this condition gracefully.
> > We already tolerate booting the EFI stub with the caches off (even
> > though this violates the EFI spec as well), and so we should deal
> > with HYP mode boot with MMU and caches either on or off.
> >
> > - When the MMU and caches are on, we can ignore the HYP stub altogether,
> > since we can just use the existing mappings, and just branch into
> > the decompressed kernel as usual after disabling MMU and caches.
> >
> > - When the MMU and caches are off, we have to drop to SVC mode so that
> > we can set up the page tables using short descriptors. In this case,
> > we need to install the HYP stub so that we can return to HYP mode
> > when handing over to the kernel proper.
> >
> > Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
> > ---
> > arch/arm/boot/compressed/head.S | 29 +++++++++++++++++++++++++++++
> > 1 file changed, 29 insertions(+)
> >
> > diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> > index c79db44ba128..986db86ba334 100644
> > --- a/arch/arm/boot/compressed/head.S
> > +++ b/arch/arm/boot/compressed/head.S
> > @@ -1436,6 +1436,35 @@ ENTRY(efi_enter_kernel)
> > mrc p15, 0, r0, c1, c0, 0 @ read SCTLR
> > tst r0, #0x1 @ MMU enabled?
> > orreq r4, r4, #1 @ set LSB if not
> > +#ifdef CONFIG_ARM_VIRT_EXT
> > + @
> > + @ The EFI spec does not support booting on ARM in HYP mode,
> > + @ since it mandates that the MMU and caches are on, with all
> > + @ 32-bit addressable DRAM mapped 1:1 using short descriptors.
> > + @ While the EDK2 reference implementation adheres to this,
> > + @ U-Boot might decide to enter the EFI stub in HYP mode anyway,
> > + @ with the MMU and caches either on or off.
> > + @ In the former case, we're better off just carrying on using
> > + @ the cached 1:1 mapping that the firmware provided, and pretend
> > + @ that we are in SVC mode as far as the decompressor is
> > + @ concerned. However, if the caches are off, we need to drop
> > + @ into SVC mode now, and let the decompressor set up its cached
> > + @ 1:1 mapping as usual.
> > + @
> > + mov r0, #SVC_MODE
> > + msr spsr_cxsf, r0 @ record that we are in SVC mode
> > + bne 1f @ skip HYP stub install if MMU is on
> > +
> > + mov r9, r4 @ preserve image base
> > + bl __hyp_stub_install @ returns boot mode in r4
> > + cmp r4, #HYP_MODE @ did we boot in HYP?
> > + bne 1f @ skip drop to SVC if we did not
> > +
> > + safe_svcmode_maskall r0
> > + msr spsr_cxsf, r4 @ record boot mode
> > + mov r4, r9 @ restore image base
> > +1:
> > +#endif
> >
> > mov r0, r8 @ DT start
> > add r1, r8, r2 @ DT end
> >
>
_______________________________________________
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 06/11] gpio: add support for the sl28cpld GPIO controller
From: Michael Walle @ 2020-06-05 12:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Andy Shevchenko, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <CAHp75VfRhL1f-XD=PMbqd3BLeJQzQMFAupSzqAvx0g7-X_2VhQ@mail.gmail.com>
Am 2020-06-05 14:00, schrieb Andy Shevchenko:
> On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
>
>> Add support for the GPIO controller of the sl28 board management
>> controller. This driver is part of a multi-function device.
>>
>> A controller has 8 lines. There are three different flavors:
>> full-featured GPIO with interrupt support, input-only and output-only.
>
> ...
>
>> +#include <linux/of_device.h>
>
> I think also not needed.
> But wait...
>
>> + return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev),
>> regmap,
>
> It seems regmap needs to be converted to use fwnode.
Mhh, this _np functions was actually part of this series in the
beginning.
>> + irq, IRQF_SHARED |
>> IRQF_ONESHOT, 0,
>> + irq_chip, &gpio->irq_data);
>
> ...
>
>> + if (!pdev->dev.parent)
>> + return -ENODEV;
>
> Are we expecting to get shot into foot? I mean why we need this check?
Can we be sure, that we always have a parent node? You are the first
which complains about this ;) There were some other comments to move
this to the beginning of the function.
>
>> + dev_id = platform_get_device_id(pdev);
>> + if (dev_id)
>> + type = dev_id->driver_data;
>
> Oh, no. In new code we don't need this. We have facilities to provide
> platform data in a form of fwnode.
Ok I'll look into that.
But I already have a question, so there are of_property_read_xx(), which
seems to be the old functions, then there is device_property_read_xx()
and
fwnode_property_read_xx(). What is the difference between the latter
two?
>
>> + else
>> + type =
>> (uintptr_t)of_device_get_match_data(&pdev->dev);
>
> So does this. device_get_match_data().
ok
>
>> + if (!type)
>> + return -ENODEV;
>
> ...
>
>> + if (irq_support &&
>
> Why do you need this flag? Can't simple IRQ number be sufficient?
I want to make sure, the is no misconfiguration. Eg. only GPIO
flavors which has irq_support set, have the additional interrupt
registers.
>
>> + device_property_read_bool(&pdev->dev,
>> "interrupt-controller")) {
>> + irq = platform_get_irq(pdev, 0);
>> + if (irq < 0)
>> + return irq;
>> +
>> + ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
>> + base, irq);
>> + if (ret)
>> + return ret;
>> +
>> + config.irq_domain =
>> regmap_irq_get_domain(gpio->irq_data);
>> + }
>
> ...
>
>> +static const struct of_device_id sl28cpld_gpio_of_match[] = {
>
>> + { .compatible = "kontron,sl28cpld-gpio",
>> + .data = (void *)SL28CPLD_GPIO },
>> + { .compatible = "kontron,sl28cpld-gpi",
>> + .data = (void *)SL28CPLD_GPI },
>> + { .compatible = "kontron,sl28cpld-gpo",
>> + .data = (void *)SL28CPLD_GPO },
>
> All above can be twice less LOCs.
They are longer than 80 chars. Or do I miss something?
>
>> + {},
>
> No comma.
ok
>> +};
>
>
> ...
>
>> + .name = KBUILD_MODNAME,
>
> This actually not good idea in long term. File name can change and
> break an ABI.
Ahh an explanation, why this is bad. Ok makes sense, although to be
fair,
.id_table should be used for the driver name matching. I'm not sure if
this is used somewhere else, though.
--
-michael
_______________________________________________
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 21/25] clk: bcm: rpi: Discover the firmware clocks
From: Nicolas Saenz Julienne @ 2020-06-05 12:45 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, Stephen Boyd, Michael Turquette,
linux-kernel, linux-clk, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel
In-Reply-To: <d3791b14fceec639085ff427e934852f275e348c.1590594293.git-series.maxime@cerno.tech>
[-- Attachment #1.1: Type: text/plain, Size: 12850 bytes --]
Hi Maxime,
On Wed, 2020-05-27 at 17:45 +0200, Maxime Ripard wrote:
> The RaspberryPi4 firmware actually exposes more clocks than are currently
> handled by the driver and we will need to change some of them directly
> based on the pixel rate for the display related clocks, or the load for the
> GPU.
>
> Since the firmware implements DVFS, this rate change can have a number of
> side-effects, including adjusting the various PLL voltages or the PLL
> parents. The firmware also implements thermal throttling, so even some
> thermal pressure can change those parameters behind Linux back.
>
> DVFS is currently implemented on the arm, core, h264, v3d, isp and hevc
> clocks, so updating any of them using the MMIO driver (and thus behind the
> firmware's back) can lead to troubles, the arm clock obviously being the
> most problematic.
>
> In order to make Linux play as nice as possible with those constraints, it
> makes sense to rely on the firmware clocks as much as possible. However,
> the firmware doesn't seem to provide some equivalents to their MMIO
> counterparts, so we can't really replace that driver entirely.
>
> Fortunately, the firmware has an interface to discover the clocks it
> exposes.
>
> Let's use it to discover, register the clocks in the clocks framework and
> then expose them through the device tree for consumers to use them.
>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: linux-clk@vger.kernel.org
> Reviewed-by: Stephen Boyd <sboyd@kernel.org>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/clk/bcm/clk-raspberrypi.c | 151 ++++++++++++++++++++--
> include/soc/bcm2835/raspberrypi-firmware.h | 5 +-
> 2 files changed, 144 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> raspberrypi.c
> index eebd16040f8a..8d3acf3ee053 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -296,6 +296,142 @@ static struct clk_hw
> *raspberrypi_register_pllb_arm(struct raspberrypi_clk *rpi)
> return &raspberrypi_clk_pllb_arm.hw;
> }
>
> +static int raspberrypi_fw_dumb_determine_rate(struct clk_hw *hw,
> + struct clk_rate_request *req)
> +{
> + /*
> + * The firmware will do the rounding but that isn't part of
> + * the interface with the firmware, so we just do our best
> + * here.
> + */
> + req->rate = clamp(req->rate, req->min_rate, req->max_rate);
> + return 0;
> +}
> +
> +static const struct clk_ops raspberrypi_firmware_clk_ops = {
> + .is_prepared = raspberrypi_fw_is_prepared,
> + .recalc_rate = raspberrypi_fw_get_rate,
> + .determine_rate = raspberrypi_fw_dumb_determine_rate,
> + .set_rate = raspberrypi_fw_set_rate,
> +};
> +
> +static struct clk_hw *raspberrypi_clk_register(struct raspberrypi_clk *rpi,
> + unsigned int parent,
> + unsigned int id)
> +{
> + struct raspberrypi_clk_data *data;
> + struct clk_init_data init = {};
> + u32 min_rate, max_rate;
> + int ret;
> +
> + if (id == RPI_FIRMWARE_ARM_CLK_ID) {
> + struct clk_hw *hw;
> +
> + hw = raspberrypi_register_pllb(rpi);
> + if (IS_ERR(hw)) {
> + dev_err(rpi->dev, "Failed to initialize pllb, %ld\n",
> + PTR_ERR(hw));
> + return hw;
> + }
> +
> + return raspberrypi_register_pllb_arm(rpi);
> + }
> +
> + data = devm_kzalloc(rpi->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return ERR_PTR(-ENOMEM);
> + data->rpi = rpi;
> + data->id = id;
> +
> + init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
> + init.ops = &raspberrypi_firmware_clk_ops;
> + init.flags = CLK_GET_RATE_NOCACHE;
> +
> + data->hw.init = &init;
> +
> + ret = raspberrypi_clock_property(rpi->firmware, data,
> + RPI_FIRMWARE_GET_MIN_CLOCK_RATE,
> + &min_rate);
> + if (ret) {
> + dev_err(rpi->dev, "Failed to get clock %d min freq: %d",
> + id, ret);
> + return ERR_PTR(ret);
> + }
> +
> + ret = raspberrypi_clock_property(rpi->firmware, data,
> + RPI_FIRMWARE_GET_MAX_CLOCK_RATE,
> + &max_rate);
> + if (ret) {
> + dev_err(rpi->dev, "Failed to get clock %d max freq: %d\n",
> + id, ret);
> + return ERR_PTR(ret);
> + }
> +
> + dev_info(rpi->dev, "Clock %d frequency range: min %u, max %u\n",
> + id, min_rate, max_rate);
This outputs:
[ 9.071965] raspberrypi-clk soc:firmware:clocks: Clock arm frequency range: min 600000000, max 1500000000
[ 9.086115] raspberrypi-clk soc:firmware:clocks: Clock core frequency range: min 200000000, max 500000000
[ 9.102418] raspberrypi-clk soc:firmware:clocks: Clock v3d frequency range: min 250000000, max 500000000
[ 9.120260] raspberrypi-clk soc:firmware:clocks: Clock m2mc frequency range: min 0, max 600000000
I think, arm aside, it's pretty useless. I'd either print it only for arm or
drop it altogether.
> +
> + ret = devm_clk_hw_register(rpi->dev, &data->hw);
> + if (ret)
> + return ERR_PTR(ret);
> +
> + clk_hw_set_rate_range(&data->hw, min_rate, max_rate);
> +
> + if (id == RPI_FIRMWARE_ARM_CLK_ID) {
> + ret = devm_clk_hw_register_clkdev(rpi->dev, &data->hw,
> + NULL, "cpu0");
> + if (ret) {
> + dev_err(rpi->dev, "Failed to initialize clkdev\n");
> + return ERR_PTR(ret);
> + }
> + }
> +
> + return &data->hw;
> +}
> +
> +static int raspberrypi_discover_clocks(struct raspberrypi_clk *rpi,
> + struct clk_hw_onecell_data *data)
> +{
> + struct rpi_firmware_get_clocks_response *clks;
> + int ret;
> +
> + clks = devm_kcalloc(rpi->dev,
> + sizeof(*clks), RPI_FIRMWARE_NUM_CLK_ID,
> + GFP_KERNEL);
> + if (!clks)
> + return -ENOMEM;
> +
> + ret = rpi_firmware_property(rpi->firmware, RPI_FIRMWARE_GET_CLOCKS,
> + clks,
> + sizeof(*clks) * RPI_FIRMWARE_NUM_CLK_ID);
> + if (ret)
> + return ret;
> +
> + while (clks->id) {
> + struct clk_hw *hw;
> +
> + switch (clks->id) {
> + case RPI_FIRMWARE_ARM_CLK_ID:
> + case RPI_FIRMWARE_CORE_CLK_ID:
> + case RPI_FIRMWARE_M2MC_CLK_ID:
> + case RPI_FIRMWARE_V3D_CLK_ID:
> + hw = raspberrypi_clk_register(rpi, clks->parent,
> + clks->id);
> + if (IS_ERR(hw))
> + return PTR_ERR(hw);
> +
> + data->hws[clks->id] = hw;
> + data->num = clks->id + 1;
> + fallthrough;
> +
> + default:
> + clks++;
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +
> static int raspberrypi_clk_probe(struct platform_device *pdev)
> {
> struct clk_hw_onecell_data *clk_data;
> @@ -303,7 +439,6 @@ static int raspberrypi_clk_probe(struct platform_device
> *pdev)
> struct device *dev = &pdev->dev;
> struct rpi_firmware *firmware;
> struct raspberrypi_clk *rpi;
> - struct clk_hw *hw;
> int ret;
>
> /*
> @@ -340,17 +475,9 @@ static int raspberrypi_clk_probe(struct platform_device
> *pdev)
> if (!clk_data)
> return -ENOMEM;
>
> - hw = raspberrypi_register_pllb(rpi);
> - if (IS_ERR(hw)) {
> - dev_err(dev, "Failed to initialize pllb, %ld\n", PTR_ERR(hw));
> - return PTR_ERR(hw);
> - }
> -
> - hw = raspberrypi_register_pllb_arm(rpi);
> - if (IS_ERR(hw))
> - return PTR_ERR(hw);
> - clk_data->hws[RPI_FIRMWARE_ARM_CLK_ID] = hw;
> - clk_data->num = RPI_FIRMWARE_ARM_CLK_ID + 1;
> + ret = raspberrypi_discover_clocks(rpi, clk_data);
> + if (ret)
> + return ret;
>
> ret = devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
> clk_data);
> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h
> b/include/soc/bcm2835/raspberrypi-firmware.h
> index 3025aca3c358..1c48f8269eab 100644
> --- a/include/soc/bcm2835/raspberrypi-firmware.h
> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
> @@ -136,6 +136,11 @@ enum rpi_firmware_property_tag {
> RPI_FIRMWARE_GET_DMA_CHANNELS = 0x00060001,
> };
>
> +struct rpi_firmware_get_clocks_response {
> + __le32 parent;
> + __le32 id;
> +};
> +
As per other firmware consumer drivers, this should be moved into
clk-raspberrypi.c. Also I'd switch to using u32. It's pretty clear this will be
used only on this platform, so no need to worry about endianness (also common
practice among rpi firmware consumer drivers).
> #if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
> int rpi_firmware_property(struct rpi_firmware *fw,
> u32 tag, void *data, size_t len);
Here's the clk_summary output:
enable prepare protect duty
clock count count count rate accuracy phase cycle
---------------------------------------------------------------------------------------------
fw-clk-m2mc 0 0 0 149984992 0 0 50000
fw-clk-v3d 0 0 0 250000000 0 0 50000
fw-clk-core 0 0 0 200000000 0 0 50000
fw-clk-arm 0 0 0 1500000000 0 0 50000
otg 0 0 0 480000000 0 0 50000
osc 2 2 2 54000000 0 0 50000
tsens 0 0 0 3375000 0 0 50000
otp 0 0 0 13500000 0 0 50000
timer 0 0 0 1000000 0 0 50000
plld 1 1 1 2999999988 0 0 50000
plld_dsi1 0 0 0 11718750 0 0 50000
plld_dsi0 0 0 0 11718750 0 0 50000
plld_per 5 5 4 749999997 0 0 50000
pwm 1 1 1 9999999 0 0 50000
emmc2 1 1 1 99999999 0 0 50000
emmc 1 1 1 249999999 0 0 50000
uart 1 1 1 47999999 0 0 50000
plld_core 0 0 0 599999998 0 0 50000
pllc 1 1 1 3000000091 0 0 50000
pllc_per 0 0 0 600000019 0 0 50000
pllc_core2 0 0 0 11718751 0 0 50000
pllc_core1 0 0 0 11718751 0 0 50000
pllc_core0 1 1 1 1000000031 0 0 50000
vpu 5 5 2 200000006 0 0 50000
fe804000.i2c_div 1 1 1 99901 0 0 50000
fe205000.i2c_div 1 1 1 99901 0 0 50000
aux_spi2 0 0 0 200000006 0 0 50000
aux_spi1 0 0 0 200000006 0 0 50000
aux_uart 1 1 0 200000006 0 0 50000
peri_image 0 0 0 200000006 0 0 50000
pllb 0 0 0 2999999988 0 0 50000
pllb_arm 0 0 0 599999998 0 0 50000
plla 0 0 0 2999999988 0 0 50000
plla_ccp2 0 0 0 11718750 0 0 50000
plla_dsi0 0 0 0 11718750 0 0 50000
plla_per 0 0 0 11718750 0 0 50000
plla_core 0 0 0 499999998 0 0 50000
h264 0 0 0 249999999 0 0 50000
isp 0 0 0 249999999 0 0 50000
v3d 0 0 0 249999999 0 0 50000
[...]
arm clocks don't match. CCF is caching the mmio version of the clocks, I think
we need to add CLK_GET_RATE_NOCACHE to every clock that's being handled by
firmware.
Otherwise I verified that cpufreq registers/behaves as expected.
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- 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: [V7, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Andy Shevchenko @ 2020-06-05 12:46 UTC (permalink / raw)
To: Dongchun Zhu
Cc: mark.rutland, devicetree, drinkcat, louis.kuo, srv_heupstream,
linus.walleij, shengnan.wang, tfiga, bgolaszewski, sj.huang,
robh+dt, linux-mediatek, sakari.ailus, matthias.bgg, bingbu.cao,
mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200605105412.18813-3-dongchun.zhu@mediatek.com>
On Fri, Jun 05, 2020 at 06:54:12PM +0800, Dongchun Zhu wrote:
> Add a V4L2 sub-device driver for DW9768 voice coil motor, providing
> control to set the desired focus via IIC serial interface.
...
> +config VIDEO_DW9768
> + tristate "DW9768 lens voice coil support"
> + depends on I2C && VIDEO_V4L2
No compile test?
> + depends on PM
This is very strange dependency for ordinary driver.
> + select MEDIA_CONTROLLER
> + select VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
...
> +/*
> + * DW9768 requires waiting time (delay time) of t_OPR after power-up,
> + * or in the case of PD reset taking place.
> + */
> +#define DW9768_T_OPR_US 1000
> +#define DW9768_Tvib_MS_BASE10 (64 - 1)
> +#define DW9768_AAC_MODE_DEFAULT 2
> +#define DW9768_AAC_TIME_DEFAULT 0x20
Hex? Why not decimal?
> +#define DW9768_CLOCK_PRE_SCALE_DEFAULT 1
...
> +static int dw9768_mod_reg(struct dw9768 *dw9768, u8 reg, u8 mask, u8 val)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> + int ret;
> +
> + ret = i2c_smbus_read_byte_data(client, reg);
> + if (ret < 0)
> + return ret;
> +
> + val = ((unsigned char)ret & ~mask) | (val & mask);
This cast is weird.
> +
> + return i2c_smbus_write_byte_data(client, reg, val);
> +}
...
> + dev_err(&client->dev, "%s I2C failure: %d",
> + __func__, ret);
One line?
...
> +static int dw9768_release(struct dw9768 *dw9768)
> +{
> + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> + u32 move_delay_us = dw9768_cal_move_delay(dw9768->aac_mode,
> + dw9768->clock_presc,
> + dw9768->aac_timing) / 100;
> + int ret, val;
> +
> + val = round_down(dw9768->focus->val, DW9768_MOVE_STEPS);
> + for ( ; val >= 0; val -= DW9768_MOVE_STEPS) {
> + ret = dw9768_set_dac(dw9768, val);
> + if (ret) {
> + dev_err(&client->dev, "I2C write fail: %d", ret);
> + return ret;
> + }
> + usleep_range(move_delay_us, move_delay_us + 1000);
> + }
It will look more naturally in the multiplier kind of value.
unsigned int steps = DIV_ROUND_UP(...);
while (steps--) {
...(..., steps * ..._MOVE_STEPS);
...
}
but double check arithmetics.
> + return 0;
> +}
Also it seems we need to have writex_poll_timeout() implementation (see
iopoll.h).
--
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 v3 22/25] clk: bcm: rpi: Give firmware clocks a name
From: Nicolas Saenz Julienne @ 2020-06-05 12:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel
In-Reply-To: <135a5d32e42d9a117e264f1f52ac9fb6b9dc20e6.1590594293.git-series.maxime@cerno.tech>
[-- Attachment #1.1: Type: text/plain, Size: 2443 bytes --]
On Wed, 2020-05-27 at 17:45 +0200, Maxime Ripard wrote:
> We've registered the firmware clocks using their ID as name, but it's much
> more convenient to register them using their proper name. Since the
> firmware doesn't provide it, we have to duplicate it.
>
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
> drivers/clk/bcm/clk-raspberrypi.c | 25 ++++++++++++++++++++++---
> 1 file changed, 22 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> raspberrypi.c
> index 8d3acf3ee053..cee634cb5323 100644
> --- a/drivers/clk/bcm/clk-raspberrypi.c
> +++ b/drivers/clk/bcm/clk-raspberrypi.c
> @@ -36,6 +36,23 @@ enum rpi_firmware_clk_id {
> RPI_FIRMWARE_NUM_CLK_ID,
> };
>
> +static char *rpi_firmware_clk_names[] = {
> + [RPI_FIRMWARE_EMMC_CLK_ID] = "emmc",
> + [RPI_FIRMWARE_UART_CLK_ID] = "uart",
> + [RPI_FIRMWARE_ARM_CLK_ID] = "arm",
> + [RPI_FIRMWARE_CORE_CLK_ID] = "core",
> + [RPI_FIRMWARE_V3D_CLK_ID] = "v3d",
> + [RPI_FIRMWARE_H264_CLK_ID] = "h264",
> + [RPI_FIRMWARE_ISP_CLK_ID] = "isp",
> + [RPI_FIRMWARE_SDRAM_CLK_ID] = "sdram",
> + [RPI_FIRMWARE_PIXEL_CLK_ID] = "pixel",
> + [RPI_FIRMWARE_PWM_CLK_ID] = "pwm",
> + [RPI_FIRMWARE_HEVC_CLK_ID] = "hevc",
> + [RPI_FIRMWARE_EMMC2_CLK_ID] = "emmc2",
> + [RPI_FIRMWARE_M2MC_CLK_ID] = "m2mc",
> + [RPI_FIRMWARE_PIXEL_BVB_CLK_ID] = "pixel-bvb",
> +};
> +
> #define RPI_FIRMWARE_STATE_ENABLE_BIT BIT(0)
> #define RPI_FIRMWARE_STATE_WAIT_BIT BIT(1)
>
> @@ -343,7 +360,9 @@ static struct clk_hw *raspberrypi_clk_register(struct
> raspberrypi_clk *rpi,
> data->rpi = rpi;
> data->id = id;
>
> - init.name = devm_kasprintf(rpi->dev, GFP_KERNEL, "fw-clk-%u", id);
> + init.name = devm_kasprintf(rpi->dev, GFP_KERNEL,
> + "fw-clk-%s",
> + rpi_firmware_clk_names[id]);
> init.ops = &raspberrypi_firmware_clk_ops;
> init.flags = CLK_GET_RATE_NOCACHE;
>
> @@ -367,8 +386,8 @@ static struct clk_hw *raspberrypi_clk_register(struct
> raspberrypi_clk *rpi,
> return ERR_PTR(ret);
> }
>
> - dev_info(rpi->dev, "Clock %d frequency range: min %u, max %u\n",
> - id, min_rate, max_rate);
> + dev_info(rpi->dev, "Clock %s frequency range: min %u, max %u\n",
> + rpi_firmware_clk_names[id], min_rate, max_rate);
I belive this might change. Otherwise:
Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Regards,
Nicolas
[-- Attachment #1.2: This is a digitally signed message part --]
[-- 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] iommu/mediatek: Use totalram_pages to setup enable_4GB
From: David Hildenbrand @ 2020-06-05 12:52 UTC (permalink / raw)
To: Christoph Hellwig
Cc: wsd_upstream, Joerg Roedel, iommu, linux-kernel, Chao Hao,
Miles Chen, linux-mediatek, linux-arm-kernel, Matthias Brugger,
yingjoe.chen, Yong Wu
In-Reply-To: <f62c9623-bf5c-6fdb-afa5-9ff04c8fde70@redhat.com>
On 04.06.20 17:27, David Hildenbrand wrote:
> On 04.06.20 17:06, Christoph Hellwig wrote:
>> On Thu, Jun 04, 2020 at 01:32:40PM +0200, David Hildenbrand wrote:
>>> Just a thought: If memory hotplug is applicable as well, you might
>>> either want to always assume data->enable_4GB, or handle memory hotplug
>>> events from the memory notifier, when new memory gets onlined (not sure
>>> how tricky that is).
>>
>> We probably want a highest_pfn_possible() or similar API instead of
>> having drivers poking into random VM internals.
>
> Well, memory notifiers are a reasonable api used accross the kernel to
> get notified when new memory is onlined to the buddy that could be used
> for allocations.
>
> highest_pfn_possible() would have to default to something linked to
> MAX_PHYSMEM_BITS whenever memory hotplug is configured, I am not sure
> how helpful that is (IOW, you can just default to enable_4GB=true in
> that case instead in most cases).
Correction: At least on x86-64 we have max_possible_pfn, which will
consult the ACPI SRAT table to figure out the maximum possible PFN.
(Without SRAT, max_possible_pfn will point at the end of initial boot
memory and not consider hotplug memory - something that e.g., newer QEMU
versions work around by creating SRAT tables if memory hotplug might be
possible, even if there is no actual NUMA configuration).
pci-swiotlb.c similarly relies on that to figure out if there are any
!DMA addresses to handle.
--
Thanks,
David / dhildenb
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/2] mmc: sunxi-mmc: do not hide address in sunxi_mmc_irq()
From: Frank Lee @ 2020-06-05 12:55 UTC (permalink / raw)
To: chaotian.jing, ulf.hansson, matthias.bgg, mripard, wens,
tiny.windzz, rmfrfs, frank, marex, linux-mmc, linux-arm-kernel,
linux-mediatek, linux-kernel
From: Yangtao Li <tiny.windzz@gmail.com>
Using %px to show the actual address in sunxi_mmc_irq()
to help us to debug issue.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Frank Lee <frank@allwinnertech.com>
---
drivers/mmc/host/sunxi-mmc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 5e95bbc51644..dcd30c3e1fac 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -574,7 +574,7 @@ static irqreturn_t sunxi_mmc_irq(int irq, void *dev_id)
idma_int = mmc_readl(host, REG_IDST);
msk_int = mmc_readl(host, REG_MISTA);
- dev_dbg(mmc_dev(host->mmc), "irq: rq %p mi %08x idi %08x\n",
+ dev_dbg(mmc_dev(host->mmc), "irq: rq %px mi %08x idi %08x\n",
host->mrq, msk_int, idma_int);
mrq = host->mrq;
--
2.24.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/2] mmc: mediatek: do not hide address in msdc_request_timeout()
From: Frank Lee @ 2020-06-05 12:55 UTC (permalink / raw)
To: chaotian.jing, ulf.hansson, matthias.bgg, mripard, wens,
tiny.windzz, rmfrfs, frank, marex, linux-mmc, linux-arm-kernel,
linux-mediatek, linux-kernel
In-Reply-To: <20200605125545.31974-1-frank@allwinnertech.com>
From: Yangtao Li <tiny.windzz@gmail.com>
Using %px to show the actual address in msdc_request_timeout()
to help us to debug issue.
Signed-off-by: Yangtao Li <tiny.windzz@gmail.com>
Signed-off-by: Frank Lee <frank@allwinnertech.com>
---
drivers/mmc/host/mtk-sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/mtk-sd.c b/drivers/mmc/host/mtk-sd.c
index 39e7fc54c438..28b4a136fc72 100644
--- a/drivers/mmc/host/mtk-sd.c
+++ b/drivers/mmc/host/mtk-sd.c
@@ -1411,7 +1411,7 @@ static void msdc_request_timeout(struct work_struct *work)
/* simulate HW timeout status */
dev_err(host->dev, "%s: aborting cmd/data/mrq\n", __func__);
if (host->mrq) {
- dev_err(host->dev, "%s: aborting mrq=%p cmd=%d\n", __func__,
+ dev_err(host->dev, "%s: aborting mrq=%px cmd=%d\n", __func__,
host->mrq, host->mrq->cmd->opcode);
if (host->cmd) {
dev_err(host->dev, "%s: aborting cmd=%d\n",
--
2.24.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: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.
From: Robin Murphy @ 2020-06-05 12:58 UTC (permalink / raw)
To: Will Deacon, Mark Brown
Cc: fujun (F), Wuxuecheng, Lixin (Victor, Kirin),
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200605123302.GA19936@willie-the-truck>
On 2020-06-05 13:33, Will Deacon wrote:
> On Fri, Jun 05, 2020 at 01:10:29PM +0100, Mark Brown wrote:
>> On Mon, Jun 01, 2020 at 08:03:12AM +0100, Will Deacon wrote:
>>> On Fri, May 29, 2020 at 09:03:37AM +0000, Lixin (Victor, Kirin) wrote:
>>
>>>> Intel optimized getcpu syscall on Linux/Android system by using vDSO, but
>>>> ARM doesn't do any optimizations for getcpu syscall.
>>
>>>> In Apple open source, TPIDRRO_EL0/TPIDRURO is used to save the CPU number,
>>>> [1]https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/arm/cswitch.s.auto.html
>>
>>>> Is there any risk if using TPIDRRO_EL0/TPIDRURO to implement
>>>> the vDSO for getcpu? Is there any possible to break any ARM ABI? Can you
>>>> help us to confirm the considerations?
>>
>>> Do you have a use-case for high-performance getcpu() that isn't better
>>> suited to rseq()?
>>
>> I actually have an implementation of this that I'd been waiting for the
>> end of the merge window to post, largely because I first heard of the
>> use of restartable sequences for this after I'd already implemented the
>> vDSO version - this stuff is not as discoverable as one might desire.
>> It doesn't store the CPU ID directly in TPIDRRO but rather uses TPIDDRRO
>> to store the offset of a per-CPU struct in the vDSO data in order to
>> allow for the addition of further data in the future. I'll post it
>> today for discussion.
>>
>> The latest version of the Mathieu's glibc integration patches is:
>>
>> https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficios.com/
>>
>> The only things I can see where the vDSO does better are support for the
>> node parameter of getcpu() and the ease of implementation for the users,
>> the restartable sequences code was merged all the way back in v4.18 and
>> it's still not used by any of the libcs as far as I can see. The node
>> to CPU mapping is static so I'm not sure how exciting that is, it could
>> be looked up separately when processing data if it's important, but the
>> ease of use feels like something.
>>
>> One important caveat with using TPIDRRO is that if KPTI is active then
>> the KPTI trampoline uses TPIDRRO as a scratch register so unless we can
>> find another register for scratch usage the user would need to give up
>> the protections offered by KPTI or run on future hardware which can use
>> E0PD instead. This severely limits the usefulness on current systems.
>
> We only trash TPIDRRO on entry, so I think you could repopulate it on every
> exception from userspace and it *should* work with KPTI (famous last words!)
Is that not already the case given that we keep TLS gubbins in there for
compat tasks?
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [V7, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Tomasz Figa @ 2020-06-05 13:02 UTC (permalink / raw)
To: Sakari Ailus, Dongchun Zhu
Cc: mark.rutland, drinkcat, andriy.shevchenko, srv_heupstream,
devicetree, linus.walleij, shengnan.wang, bgolaszewski, sj.huang,
robh+dt, linux-mediatek, Dongchun Zhu, louis.kuo, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200605121459.GS16711@paasikivi.fi.intel.com>
On Fri, Jun 05, 2020 at 03:14:59PM +0300, Sakari Ailus wrote:
> Hi Dongchun,
>
> Thank you for the update.
>
> On Fri, Jun 05, 2020 at 06:54:12PM +0800, Dongchun Zhu wrote:
> > Add a V4L2 sub-device driver for DW9768 voice coil motor, providing
> > control to set the desired focus via IIC serial interface.
> >
> > Signed-off-by: Dongchun Zhu <dongchun.zhu@mediatek.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/media/i2c/Kconfig | 13 ++
> > drivers/media/i2c/Makefile | 1 +
> > drivers/media/i2c/dw9768.c | 566 +++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 581 insertions(+)
> > create mode 100644 drivers/media/i2c/dw9768.c
[snip]
> > +static int dw9768_runtime_suspend(struct device *dev)
> > +{
> > + struct i2c_client *client = to_i2c_client(dev);
> > + struct v4l2_subdev *sd = i2c_get_clientdata(client);
> > + struct dw9768 *dw9768 = sd_to_dw9768(sd);
> > +
> > + dw9768_release(dw9768);
> > + regulator_bulk_disable(ARRAY_SIZE(dw9768_supply_names),
> > + dw9768->supplies);
> > +
> > + return 0;
> > +}
> > +
> > +static int dw9768_runtime_resume(struct device *dev)
>
> __maybe_unused for this and the suspend callback.
>
These are always used. If runtime PM is disabled, they are called
explicitly in probe and remove.
Best regards,
Tomasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Please help to confirm the risk if using TPIDRRO_EL0 to save CPU number, thanks.
From: Will Deacon @ 2020-06-05 13:02 UTC (permalink / raw)
To: Robin Murphy
Cc: fujun (F), Mark Brown, Wuxuecheng, Lixin (Victor, Kirin),
linux-arm-kernel@lists.infradead.org
In-Reply-To: <a46ddb53-2226-c9c3-bf3f-0fcc5d924b1e@arm.com>
On Fri, Jun 05, 2020 at 01:58:39PM +0100, Robin Murphy wrote:
> On 2020-06-05 13:33, Will Deacon wrote:
> > On Fri, Jun 05, 2020 at 01:10:29PM +0100, Mark Brown wrote:
> > > On Mon, Jun 01, 2020 at 08:03:12AM +0100, Will Deacon wrote:
> > > > On Fri, May 29, 2020 at 09:03:37AM +0000, Lixin (Victor, Kirin) wrote:
> > >
> > > > > Intel optimized getcpu syscall on Linux/Android system by using vDSO, but
> > > > > ARM doesn't do any optimizations for getcpu syscall.
> > >
> > > > > In Apple open source, TPIDRRO_EL0/TPIDRURO is used to save the CPU number,
> > > > > [1]https://opensource.apple.com/source/xnu/xnu-4570.1.46/osfmk/arm/cswitch.s.auto.html
> > >
> > > > > Is there any risk if using TPIDRRO_EL0/TPIDRURO to implement
> > > > > the vDSO for getcpu? Is there any possible to break any ARM ABI? Can you
> > > > > help us to confirm the considerations?
> > >
> > > > Do you have a use-case for high-performance getcpu() that isn't better
> > > > suited to rseq()?
> > >
> > > I actually have an implementation of this that I'd been waiting for the
> > > end of the merge window to post, largely because I first heard of the
> > > use of restartable sequences for this after I'd already implemented the
> > > vDSO version - this stuff is not as discoverable as one might desire.
> > > It doesn't store the CPU ID directly in TPIDRRO but rather uses TPIDDRRO
> > > to store the offset of a per-CPU struct in the vDSO data in order to
> > > allow for the addition of further data in the future. I'll post it
> > > today for discussion.
> > >
> > > The latest version of the Mathieu's glibc integration patches is:
> > >
> > > https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficios.com/
> > >
> > > The only things I can see where the vDSO does better are support for the
> > > node parameter of getcpu() and the ease of implementation for the users,
> > > the restartable sequences code was merged all the way back in v4.18 and
> > > it's still not used by any of the libcs as far as I can see. The node
> > > to CPU mapping is static so I'm not sure how exciting that is, it could
> > > be looked up separately when processing data if it's important, but the
> > > ease of use feels like something.
> > >
> > > One important caveat with using TPIDRRO is that if KPTI is active then
> > > the KPTI trampoline uses TPIDRRO as a scratch register so unless we can
> > > find another register for scratch usage the user would need to give up
> > > the protections offered by KPTI or run on future hardware which can use
> > > E0PD instead. This severely limits the usefulness on current systems.
> >
> > We only trash TPIDRRO on entry, so I think you could repopulate it on every
> > exception from userspace and it *should* work with KPTI (famous last words!)
>
> Is that not already the case given that we keep TLS gubbins in there for
> compat tasks?
No; we only trash TPIDRRO for 64-bit tasks. 32-bit tasks have loads of
free registers :D
Will
_______________________________________________
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 0/3] DCMI set minimum cpufreq requirement
From: Benjamin Gaignard @ 2020-06-05 13:05 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
This series allow to STM32 camera interface (DCMI) to require a minimum
frequency to the CPUs before start streaming frames from the sensor.
The minimum frequency requirement is provided in the devide-tree node.
Setting a minimum frequency for the CPUs is needed to ensure a quick handling
of the interrupts between two sensor frames and avoid dropping half of them.
version 4:
- simplify irq affinity handling by using only dcmi_irq_notifier_notify()
version 3:
- add a cpumask field to track boosted CPUs
- add irq_affinity_notify callback
- protect cpumask field with a mutex
Benjamin Gaignard (3):
dt-bindings: media: stm32-dcmi: Add DCMI min frequency property
media: stm32-dcmi: Set minimum cpufreq requirement
ARM: dts: stm32: Set DCMI frequency requirement for stm32mp15x
.../devicetree/bindings/media/st,stm32-dcmi.yaml | 8 ++
arch/arm/boot/dts/stm32mp151.dtsi | 1 +
drivers/media/platform/stm32/stm32-dcmi.c | 122 +++++++++++++++++++--
3 files changed, 123 insertions(+), 8 deletions(-)
--
2.15.0
_______________________________________________
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 1/3] dt-bindings: media: stm32-dcmi: Add DCMI min frequency property
From: Benjamin Gaignard @ 2020-06-05 13:05 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200605130519.4184-1-benjamin.gaignard@st.com>
Document st,stm32-dcmi-min-frequency property which is used to
request CPUs minimum frequency when streaming frames.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 3fe778cb5cc3..05ca85a2411a 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -44,6 +44,13 @@ properties:
bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt.
+ st,stm32-dcmi-min-frequency:
+ description: DCMI minimum CPUs frequency requirement (in KHz).
+ allOf:
+ - $ref: /schemas/types.yaml#/definitions/uint32
+ - minimum: 0
+ - default: 0
+
required:
- compatible
- reg
@@ -71,6 +78,7 @@ examples:
clock-names = "mclk";
dmas = <&dmamux1 75 0x400 0x0d>;
dma-names = "tx";
+ st,stm32-dcmi-min-frequency = <650000>;
port {
dcmi_0: endpoint {
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: stm32: Set DCMI frequency requirement for stm32mp15x
From: Benjamin Gaignard @ 2020-06-05 13:05 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200605130519.4184-1-benjamin.gaignard@st.com>
Make sure that CPUs will at least run at 650Mhz when streaming
sensor frames.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
arch/arm/boot/dts/stm32mp151.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/stm32mp151.dtsi b/arch/arm/boot/dts/stm32mp151.dtsi
index 3ea05ba48215..f6d7bf4f8231 100644
--- a/arch/arm/boot/dts/stm32mp151.dtsi
+++ b/arch/arm/boot/dts/stm32mp151.dtsi
@@ -1091,6 +1091,7 @@
clock-names = "mclk";
dmas = <&dmamux1 75 0x400 0x0d>;
dma-names = "tx";
+ st,stm32-dcmi-min-frequency = <650000>;
status = "disabled";
};
--
2.15.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 2/3] media: stm32-dcmi: Set minimum cpufreq requirement
From: Benjamin Gaignard @ 2020-06-05 13:05 UTC (permalink / raw)
To: hugues.fruchet, mchehab, mcoquelin.stm32, alexandre.torgue
Cc: Benjamin Gaignard, rjw, linux-kernel, linux-stm32,
valentin.schneider, linux-arm-kernel, linux-media
In-Reply-To: <20200605130519.4184-1-benjamin.gaignard@st.com>
Before start streaming set cpufreq minimum frequency requirement.
The cpufreq governor will adapt the frequencies and we will have
no latency for handling interrupts.
The frequency requirement is retrieved from the device-tree node.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
---
version 4:
- simplify irq affinity handling by using only dcmi_irq_notifier_notify()
drivers/media/platform/stm32/stm32-dcmi.c | 122 ++++++++++++++++++++++++++++--
1 file changed, 114 insertions(+), 8 deletions(-)
diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
index b8931490b83b..c2389776a958 100644
--- a/drivers/media/platform/stm32/stm32-dcmi.c
+++ b/drivers/media/platform/stm32/stm32-dcmi.c
@@ -13,10 +13,13 @@
#include <linux/clk.h>
#include <linux/completion.h>
+#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
#include <linux/delay.h>
#include <linux/dmaengine.h>
#include <linux/init.h>
#include <linux/interrupt.h>
+#include <linux/irq.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/of.h>
@@ -99,6 +102,8 @@ enum state {
#define OVERRUN_ERROR_THRESHOLD 3
+static DEFINE_PER_CPU(struct freq_qos_request, qos_req);
+
struct dcmi_graph_entity {
struct v4l2_async_subdev asd;
@@ -133,6 +138,7 @@ struct stm32_dcmi {
struct resource *res;
struct reset_control *rstc;
int sequence;
+ int irq;
struct list_head buffers;
struct dcmi_buf *active;
@@ -173,6 +179,10 @@ struct stm32_dcmi {
struct media_device mdev;
struct media_pad vid_cap_pad;
struct media_pipeline pipeline;
+
+ u32 min_frequency;
+ cpumask_var_t boosted;
+ struct irq_affinity_notify notify;
};
static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
@@ -722,6 +732,90 @@ static void dcmi_pipeline_stop(struct stm32_dcmi *dcmi)
dcmi_pipeline_s_stream(dcmi, 0);
}
+static void dcmi_get_min_frequency(struct stm32_dcmi *dcmi)
+{
+ struct device_node *np = dcmi->mdev.dev->of_node;
+
+ dcmi->min_frequency = FREQ_QOS_MIN_DEFAULT_VALUE;
+
+ of_property_read_u32(np, "st,stm32-dcmi-min-frequency",
+ &dcmi->min_frequency);
+}
+
+static void dcmi_irq_notifier_notify(struct irq_affinity_notify *notify,
+ const cpumask_t *mask)
+{
+ struct stm32_dcmi *dcmi = container_of(notify,
+ struct stm32_dcmi,
+ notify);
+ struct cpufreq_policy *p;
+ int cpu;
+
+ /*
+ * For all boosted CPUs check if it is still the case
+ * if not remove the request
+ */
+ for_each_cpu(cpu, dcmi->boosted) {
+ if (cpumask_test_cpu(cpu, mask))
+ continue;
+
+ p = cpufreq_cpu_get(cpu);
+ if (!p)
+ continue;
+
+ freq_qos_remove_request(&per_cpu(qos_req, cpu));
+ cpumask_andnot(dcmi->boosted, dcmi->boosted, p->cpus);
+
+ cpufreq_cpu_put(p);
+ }
+
+ /*
+ * For CPUs in the mask check if they are boosted if not add
+ * a request
+ */
+ for_each_cpu(cpu, mask) {
+ if (cpumask_test_cpu(cpu, dcmi->boosted))
+ continue;
+
+ p = cpufreq_cpu_get(cpu);
+ if (!p)
+ continue;
+
+ freq_qos_add_request(&p->constraints, &per_cpu(qos_req, cpu),
+ FREQ_QOS_MIN, dcmi->min_frequency);
+ cpumask_or(dcmi->boosted, dcmi->boosted, p->cpus);
+ cpufreq_cpu_put(p);
+ }
+}
+
+static void dcmi_irq_notifier_release(struct kref *ref)
+{
+ /*
+ * This is required by affinity notifier. We don't have anything to
+ * free here.
+ */
+}
+
+static void dcmi_set_min_frequency(struct stm32_dcmi *dcmi, s32 freq)
+{
+ struct irq_affinity_notify *notify = &dcmi->notify;
+
+ if (freq) {
+ dcmi_irq_notifier_notify(notify,
+ irq_get_affinity_mask(dcmi->irq));
+
+ notify->notify = dcmi_irq_notifier_notify;
+ notify->release = dcmi_irq_notifier_release;
+ irq_set_affinity_notifier(dcmi->irq, notify);
+ } else {
+ struct cpumask clear;
+
+ irq_set_affinity_notifier(dcmi->irq, NULL);
+ cpumask_clear(&clear);
+ dcmi_irq_notifier_notify(notify, &clear);
+ }
+}
+
static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
{
struct stm32_dcmi *dcmi = vb2_get_drv_priv(vq);
@@ -736,11 +830,13 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
goto err_release_buffers;
}
+ dcmi_set_min_frequency(dcmi, dcmi->min_frequency);
+
ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
if (ret < 0) {
dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
__func__, ret);
- goto err_pm_put;
+ goto err_drop_qos;
}
ret = dcmi_pipeline_start(dcmi);
@@ -835,7 +931,8 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
err_media_pipeline_stop:
media_pipeline_stop(&dcmi->vdev->entity);
-err_pm_put:
+err_drop_qos:
+ dcmi_set_min_frequency(dcmi, FREQ_QOS_MIN_DEFAULT_VALUE);
pm_runtime_put(dcmi->dev);
err_release_buffers:
@@ -863,6 +960,8 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
media_pipeline_stop(&dcmi->vdev->entity);
+ dcmi_set_min_frequency(dcmi, FREQ_QOS_MIN_DEFAULT_VALUE);
+
spin_lock_irq(&dcmi->irqlock);
/* Disable interruptions */
@@ -1838,7 +1937,6 @@ static int dcmi_probe(struct platform_device *pdev)
struct vb2_queue *q;
struct dma_chan *chan;
struct clk *mclk;
- int irq;
int ret = 0;
match = of_match_device(of_match_ptr(stm32_dcmi_of_match), &pdev->dev);
@@ -1879,9 +1977,9 @@ static int dcmi_probe(struct platform_device *pdev)
dcmi->bus.bus_width = ep.bus.parallel.bus_width;
dcmi->bus.data_shift = ep.bus.parallel.data_shift;
- irq = platform_get_irq(pdev, 0);
- if (irq <= 0)
- return irq ? irq : -ENXIO;
+ dcmi->irq = platform_get_irq(pdev, 0);
+ if (dcmi->irq <= 0)
+ return dcmi->irq ? dcmi->irq : -ENXIO;
dcmi->res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!dcmi->res) {
@@ -1895,11 +1993,12 @@ static int dcmi_probe(struct platform_device *pdev)
return PTR_ERR(dcmi->regs);
}
- ret = devm_request_threaded_irq(&pdev->dev, irq, dcmi_irq_callback,
+ ret = devm_request_threaded_irq(&pdev->dev, dcmi->irq,
+ dcmi_irq_callback,
dcmi_irq_thread, IRQF_ONESHOT,
dev_name(&pdev->dev), dcmi);
if (ret) {
- dev_err(&pdev->dev, "Unable to request irq %d\n", irq);
+ dev_err(&pdev->dev, "Unable to request irq %d\n", dcmi->irq);
return ret;
}
@@ -1930,6 +2029,9 @@ static int dcmi_probe(struct platform_device *pdev)
dcmi->state = STOPPED;
dcmi->dma_chan = chan;
+ if (!alloc_cpumask_var(&dcmi->boosted, GFP_KERNEL))
+ return -ENODEV;
+
q = &dcmi->queue;
dcmi->v4l2_dev.mdev = &dcmi->mdev;
@@ -2022,6 +2124,8 @@ static int dcmi_probe(struct platform_device *pdev)
dev_info(&pdev->dev, "Probe done\n");
+ dcmi_get_min_frequency(dcmi);
+
platform_set_drvdata(pdev, dcmi);
pm_runtime_enable(&pdev->dev);
@@ -2049,6 +2153,8 @@ static int dcmi_remove(struct platform_device *pdev)
pm_runtime_disable(&pdev->dev);
+ free_cpumask_var(dcmi->boosted);
+
v4l2_async_notifier_unregister(&dcmi->notifier);
v4l2_async_notifier_cleanup(&dcmi->notifier);
media_entity_cleanup(&dcmi->vdev->entity);
--
2.15.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 20/25] clk: bcm: rpi: Add an enum for the firmware clocks
From: Nicolas Saenz Julienne @ 2020-06-05 13:09 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tim Gover, Dave Stevenson, linux-kernel, bcm-kernel-feedback-list,
linux-rpi-kernel, Phil Elwell, linux-arm-kernel
In-Reply-To: <d8be3a45491224e0c91355131a9bcf605f38fb76.camel@suse.de>
[-- Attachment #1.1: Type: text/plain, Size: 2658 bytes --]
Hi Maxime,
On Fri, 2020-06-05 at 14:04 +0200, Nicolas Saenz Julienne wrote:
> On Wed, 2020-05-27 at 17:45 +0200, Maxime Ripard wrote:
> > While the firmware allows us to discover the available clocks, we need to
> > discriminate those clocks to only register the ones meaningful to Linux.
> > The firmware also doesn't provide a clock name, so having a list of the ID
> > will help us to give clocks a proper name later on.
> >
> > Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> > ---
> > drivers/clk/bcm/clk-raspberrypi.c | 23 +++++++++++++++++++----
> > 1 file changed, 19 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/clk/bcm/clk-raspberrypi.c b/drivers/clk/bcm/clk-
> > raspberrypi.c
> > index 5f4e2d49432f..eebd16040f8a 100644
> > --- a/drivers/clk/bcm/clk-raspberrypi.c
> > +++ b/drivers/clk/bcm/clk-raspberrypi.c
> > @@ -18,7 +18,23 @@
> >
> > #include <soc/bcm2835/raspberrypi-firmware.h>
> >
> > -#define RPI_FIRMWARE_ARM_CLK_ID 0x00000003
> > +enum rpi_firmware_clk_id {
> > + RPI_FIRMWARE_EMMC_CLK_ID = 1,
> > + RPI_FIRMWARE_UART_CLK_ID,
> > + RPI_FIRMWARE_ARM_CLK_ID,
> > + RPI_FIRMWARE_CORE_CLK_ID,
> > + RPI_FIRMWARE_V3D_CLK_ID,
> > + RPI_FIRMWARE_H264_CLK_ID,
> > + RPI_FIRMWARE_ISP_CLK_ID,
> > + RPI_FIRMWARE_SDRAM_CLK_ID,
> > + RPI_FIRMWARE_PIXEL_CLK_ID,
> > + RPI_FIRMWARE_PWM_CLK_ID,
> > + RPI_FIRMWARE_HEVC_CLK_ID,
> > + RPI_FIRMWARE_EMMC2_CLK_ID,
> > + RPI_FIRMWARE_M2MC_CLK_ID,
> > + RPI_FIRMWARE_PIXEL_BVB_CLK_ID,
> > + RPI_FIRMWARE_NUM_CLK_ID,
> > +};
> >
> > #define RPI_FIRMWARE_STATE_ENABLE_BIT BIT(0)
> > #define RPI_FIRMWARE_STATE_WAIT_BIT BIT(1)
> > @@ -31,8 +47,6 @@
> >
> > #define A2W_PLL_FRAC_BITS 20
> >
> > -#define NUM_FW_CLKS 16
> > -
> > struct raspberrypi_clk {
> > struct device *dev;
> > struct rpi_firmware *firmware;
> > @@ -320,7 +334,8 @@ static int raspberrypi_clk_probe(struct platform_device
> > *pdev)
> > rpi->firmware = firmware;
> > platform_set_drvdata(pdev, rpi);
> >
> > - clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, NUM_FW_CLKS),
> > + clk_data = devm_kzalloc(dev, struct_size(clk_data, hws,
> > + RPI_FIRMWARE_NUM_CLK_ID),
>
> nit: you're allocating one structure too many right?
Nevermind this comment, as pointed out privately by Phil Elwell, I forgot the
firmware clk description structure starts at 0. So we need to make space for
that.
It would maybe make sense to add RPI_FIRMWARE_RESERVED_CLK_ID above the EMMC
clk entry. Although it's just a suggestion.
> Acked-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
>
> Regards,
> Nicolas
>
[-- Attachment #1.2: This is a digitally signed message part --]
[-- 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: [V7, 2/2] media: i2c: dw9768: Add DW9768 VCM driver
From: Tomasz Figa @ 2020-06-05 13:10 UTC (permalink / raw)
To: Andy Shevchenko
Cc: mark.rutland, devicetree, drinkcat, srv_heupstream, linus.walleij,
shengnan.wang, louis.kuo, bgolaszewski, sj.huang, robh+dt,
linux-mediatek, Dongchun Zhu, sakari.ailus, matthias.bgg,
bingbu.cao, mchehab, linux-arm-kernel, linux-media
In-Reply-To: <20200605124643.GG2428291@smile.fi.intel.com>
Hi Andy,
On Fri, Jun 05, 2020 at 03:46:43PM +0300, Andy Shevchenko wrote:
> On Fri, Jun 05, 2020 at 06:54:12PM +0800, Dongchun Zhu wrote:
> > Add a V4L2 sub-device driver for DW9768 voice coil motor, providing
> > control to set the desired focus via IIC serial interface.
>
> ...
>
> > +config VIDEO_DW9768
> > + tristate "DW9768 lens voice coil support"
> > + depends on I2C && VIDEO_V4L2
>
> No compile test?
>
> > + depends on PM
>
> This is very strange dependency for ordinary driver.
>
> > + select MEDIA_CONTROLLER
> > + select VIDEO_V4L2_SUBDEV_API
> > + select V4L2_FWNODE
>
> ...
>
> > +/*
> > + * DW9768 requires waiting time (delay time) of t_OPR after power-up,
> > + * or in the case of PD reset taking place.
> > + */
> > +#define DW9768_T_OPR_US 1000
> > +#define DW9768_Tvib_MS_BASE10 (64 - 1)
> > +#define DW9768_AAC_MODE_DEFAULT 2
>
> > +#define DW9768_AAC_TIME_DEFAULT 0x20
>
> Hex? Why not decimal?
>
> > +#define DW9768_CLOCK_PRE_SCALE_DEFAULT 1
>
> ...
>
> > +static int dw9768_mod_reg(struct dw9768 *dw9768, u8 reg, u8 mask, u8 val)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> > + int ret;
> > +
> > + ret = i2c_smbus_read_byte_data(client, reg);
> > + if (ret < 0)
> > + return ret;
> > +
>
> > + val = ((unsigned char)ret & ~mask) | (val & mask);
>
> This cast is weird.
>
> > +
> > + return i2c_smbus_write_byte_data(client, reg, val);
> > +}
>
> ...
>
> > + dev_err(&client->dev, "%s I2C failure: %d",
> > + __func__, ret);
>
> One line?
>
> ...
>
> > +static int dw9768_release(struct dw9768 *dw9768)
> > +{
> > + struct i2c_client *client = v4l2_get_subdevdata(&dw9768->sd);
> > + u32 move_delay_us = dw9768_cal_move_delay(dw9768->aac_mode,
> > + dw9768->clock_presc,
> > + dw9768->aac_timing) / 100;
> > + int ret, val;
> > +
> > + val = round_down(dw9768->focus->val, DW9768_MOVE_STEPS);
> > + for ( ; val >= 0; val -= DW9768_MOVE_STEPS) {
> > + ret = dw9768_set_dac(dw9768, val);
> > + if (ret) {
> > + dev_err(&client->dev, "I2C write fail: %d", ret);
> > + return ret;
> > + }
> > + usleep_range(move_delay_us, move_delay_us + 1000);
> > + }
>
>
> It will look more naturally in the multiplier kind of value.
>
> unsigned int steps = DIV_ROUND_UP(...);
>
> while (steps--) {
> ...(..., steps * ..._MOVE_STEPS);
> ...
> }
>
> but double check arithmetics.
>
First of all, thank for the review!
As for this particular change suggestion, I suspect this could be a
subjective thing, because for me the current code looks more naturally
and it's what the other VCM drivers do.
> > + return 0;
> > +}
>
>
> Also it seems we need to have writex_poll_timeout() implementation (see
> iopoll.h).
What would it be supposed to do? readx_poll_timeout() repeats reading
the same registers and sleeping until a condition becomes true, which is
basically "polling". In this case we're not polling anything and we're
not writing the same value, but it's an explicit algorithm of this
driver to power down the VCM corectly.
However, given that it's quite common among VCMs to require this kind of
phased power down - we could indeed provide some V4L2 VCM helpers for open
and release.
Best regards,
Tomasz
_______________________________________________
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 06/11] gpio: add support for the sl28cpld GPIO controller
From: Andy Shevchenko @ 2020-06-05 13:15 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, Linus Walleij, Thierry Reding, Lee Jones,
Jason Cooper, Marc Zyngier, Bartosz Golaszewski,
Uwe Kleine-König, Guenter Roeck, linux-pwm, Jean Delvare,
linux-watchdog, open list:GPIO SUBSYSTEM, Mark Brown,
Thomas Gleixner, Wim Van Sebroeck, linux-arm Mailing List,
linux-hwmon, Greg Kroah-Hartman, Linux Kernel Mailing List,
Li Yang, Rob Herring, Shawn Guo
In-Reply-To: <216db3154b46bd80202873df055bb3f3@walle.cc>
On Fri, Jun 05, 2020 at 02:42:53PM +0200, Michael Walle wrote:
> Am 2020-06-05 14:00, schrieb Andy Shevchenko:
> > On Fri, Jun 5, 2020 at 12:14 AM Michael Walle <michael@walle.cc> wrote:
> > > + return devm_regmap_add_irq_chip_np(dev, dev_of_node(dev),
> > > regmap,
> >
> > It seems regmap needs to be converted to use fwnode.
>
> Mhh, this _np functions was actually part of this series in the
> beginning.
Then, please, make them fwnode aware rather than OF centric.
> > > IRQF_ONESHOT, 0,
> > > + irq_chip, &gpio->irq_data);
...
> > > + dev_id = platform_get_device_id(pdev);
> > > + if (dev_id)
> > > + type = dev_id->driver_data;
> >
> > Oh, no. In new code we don't need this. We have facilities to provide
> > platform data in a form of fwnode.
>
> Ok I'll look into that.
>
> But I already have a question, so there are of_property_read_xx(), which
> seems to be the old functions, then there is device_property_read_xx() and
> fwnode_property_read_xx(). What is the difference between the latter two?
It's easy. device_*() requires struct device to be established for this, so,
operates only against devices, while the fwnode_*() operates on pure data which
might or might not be related to any devices. If you understand OF examples
better, consider device node vs. child of such node.
...
> > > + if (irq_support &&
> >
> > Why do you need this flag? Can't simple IRQ number be sufficient?
>
> I want to make sure, the is no misconfiguration. Eg. only GPIO
> flavors which has irq_support set, have the additional interrupt
> registers.
In gpio-dwapb, for example, we simple check two things: a) hardware limitation
(if IRQ is assigned to a proper port) and b) if there is any IRQ comes from DT,
ACPI, etc.
> > > + device_property_read_bool(&pdev->dev,
> > > "interrupt-controller")) {
> > > + irq = platform_get_irq(pdev, 0);
> > > + if (irq < 0)
> > > + return irq;
> > > +
> > > + ret = sl28cpld_gpio_irq_init(&pdev->dev, gpio, regmap,
> > > + base, irq);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + config.irq_domain =
> > > regmap_irq_get_domain(gpio->irq_data);
> > > + }
...
> > > + { .compatible = "kontron,sl28cpld-gpio",
> > > + .data = (void *)SL28CPLD_GPIO },
> > > + { .compatible = "kontron,sl28cpld-gpi",
> > > + .data = (void *)SL28CPLD_GPI },
> > > + { .compatible = "kontron,sl28cpld-gpo",
> > > + .data = (void *)SL28CPLD_GPO },
> >
> > All above can be twice less LOCs.
>
> They are longer than 80 chars. Or do I miss something?
We have 100 :-)
...
> > > + .name = KBUILD_MODNAME,
> >
> > This actually not good idea in long term. File name can change and break
> > an ABI.
>
> Ahh an explanation, why this is bad. Ok makes sense, although to be fair,
> .id_table should be used for the driver name matching. I'm not sure if
> this is used somewhere else, though.
I saw in my practice chain of renames for a driver. Now, if somebody
somewhere would like to instantiate a platform driver by its name...
Oops, ABI breakage.
And of course using platform data for such device makes less sense.
--
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
* [PATCH 0/5] arm64: vdso: getcpu() support
From: Mark Brown @ 2020-06-05 13:11 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Mark Brown, Andrei Vagin, Vincenzo Frascino, linux-arm-kernel
Some applications, especially tracing ones, benefit from avoiding the
syscall overhead for getcpu() so it is common for architectures to have
vDSO implementations. Add one for arm64, using TPIDRRO_EL0 to pass a
pointer to per-CPU data rather than just store the immediate value in
order to allow for future extensibility.
It is questionable if something TPIDRRO_EL0 based is worthwhile at all
on current kernels, since v4.18 we have had support for restartable
sequences which can be used to provide a sched_getcpu() implementation
with generally better performance than the vDSO approach on
architectures which have that[1]. Work is ongoing to implement this for
glibc:
https://lore.kernel.org/lkml/20200527185130.5604-3-mathieu.desnoyers@efficios.com/
but is not yet merged and will need similar work for other userspaces.
The main advantages for the vDSO implementation are the node parameter
(though this is a static mapping to CPU number so could be looked up
separately when processing data if it's needed, it shouldn't need to be
in the hot path) and ease of implementation for users.
This is currently not compatible with KPTI due to what Will suggests is
a misunderstanding on my part about the use of TPIDRRO_EL0 by the KPTI
trampoline, since this posting is mainly for discussion of the approach
as a whole and Will only just mentioned this that's not been addressed
here.
Since we currently only have a single data page for the vDSO this will
also only currently work for lower numbered CPUs, this restriction will
be addressed separately.
There is some overlap with an in flight patch series from Andrei Vagin
supporting time namespaces in the vDSO, there shouldn't be a fundamental
issue integrating the two serieses.
This builds on work done by Kristina Martsenko some time ago but is a
new implementation.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7822b1e24f2df5df98c76f0e94a5416349ff759
Mark Brown (5):
arm64: vdso: Provide a define when building the vDSO
arm64: vdso: Add per-CPU data
arm64: vdso: Initialise the per-CPU vDSO data
arm64: vdso: Add getcpu() implementation
selftests: vdso: Support arm64 in getcpu() test
arch/arm64/include/asm/processor.h | 12 +----
arch/arm64/include/asm/vdso/datapage.h | 54 +++++++++++++++++++
arch/arm64/kernel/process.c | 26 ++++++++-
arch/arm64/kernel/vdso.c | 33 +++++++++++-
arch/arm64/kernel/vdso/Makefile | 4 +-
arch/arm64/kernel/vdso/vdso.lds.S | 1 +
arch/arm64/kernel/vdso/vgetcpu.c | 48 +++++++++++++++++
.../testing/selftests/vDSO/vdso_test_getcpu.c | 10 ++++
8 files changed, 172 insertions(+), 16 deletions(-)
create mode 100644 arch/arm64/include/asm/vdso/datapage.h
create mode 100644 arch/arm64/kernel/vdso/vgetcpu.c
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 1/5] arm64: vdso: Provide a define when building the vDSO
From: Mark Brown @ 2020-06-05 13:11 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Mark Brown, Andrei Vagin, Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20200605131131.16491-1-broonie@kernel.org>
Provide a define identifying if code is being built for the vDSO to help
with writing headers that are shared between the kernel and the vDSO.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/kernel/vdso/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
index 556d424c6f52..279b1b9fb956 100644
--- a/arch/arm64/kernel/vdso/Makefile
+++ b/arch/arm64/kernel/vdso/Makefile
@@ -27,7 +27,7 @@ ldflags-y := -shared -nostdlib -soname=linux-vdso.so.1 --hash-style=sysv \
-Bsymbolic --eh-frame-hdr --build-id -n $(btildflags-y) -T
ccflags-y := -fno-common -fno-builtin -fno-stack-protector -ffixed-x18
-ccflags-y += -DDISABLE_BRANCH_PROFILING
+ccflags-y += -DDISABLE_BRANCH_PROFILING -D__VDSO__
CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) -Os $(CC_FLAGS_SCS)
KBUILD_CFLAGS += $(DISABLE_LTO)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH 2/5] arm64: vdso: Add per-CPU data
From: Mark Brown @ 2020-06-05 13:11 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: Mark Brown, Andrei Vagin, Vincenzo Frascino, linux-arm-kernel
In-Reply-To: <20200605131131.16491-1-broonie@kernel.org>
In order to support a vDSO getcpu() implementation add per-CPU data to
the vDSO data page. Do this by wrapping the generic vdso_data struct in
an arm64 specific one with an array of per-CPU data. The offset of the
per-CPU data applying to a CPU will be stored in TPIDRRO_EL0, this
allows us to get to the per-CPU data without doing any multiplications.
Since we currently only map a single data page for the vDSO but support
very large numbers of CPUs TPIDRRO may be set to zero for CPUs which don't
fit in the data page. This will also happen when KPTI is active since
kernel_ventry uses TPIDRRO_EL0 as a scratch register in that case, add a
comment to the code explaining this.
Acessors for the data are provided in the header since they will be needed
in multiple files and it seems neater to keep things together.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/processor.h | 12 +-----
arch/arm64/include/asm/vdso/datapage.h | 54 ++++++++++++++++++++++++++
arch/arm64/kernel/process.c | 26 ++++++++++++-
arch/arm64/kernel/vdso.c | 5 ++-
4 files changed, 83 insertions(+), 14 deletions(-)
create mode 100644 arch/arm64/include/asm/vdso/datapage.h
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 240fe5e5b720..db7a804030b3 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -207,17 +207,7 @@ static inline void set_compat_ssbs_bit(struct pt_regs *regs)
regs->pstate |= PSR_AA32_SSBS_BIT;
}
-static inline void start_thread(struct pt_regs *regs, unsigned long pc,
- unsigned long sp)
-{
- start_thread_common(regs, pc);
- regs->pstate = PSR_MODE_EL0t;
-
- if (arm64_get_ssbd_state() != ARM64_SSBD_FORCE_ENABLE)
- set_ssbs_bit(regs);
-
- regs->sp = sp;
-}
+void start_thread(struct pt_regs *regs, unsigned long pc, unsigned long sp);
static inline bool is_ttbr0_addr(unsigned long addr)
{
diff --git a/arch/arm64/include/asm/vdso/datapage.h b/arch/arm64/include/asm/vdso/datapage.h
new file mode 100644
index 000000000000..e88d97238c52
--- /dev/null
+++ b/arch/arm64/include/asm/vdso/datapage.h
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020 ARM Limited
+ */
+#ifndef __ASM_VDSO_DATAPAGE_H
+#define __ASM_VDSO_DATAPAGE_H
+
+#include <vdso/datapage.h>
+
+struct vdso_cpu_data {
+ unsigned int cpu;
+ unsigned int node;
+};
+
+struct arm64_vdso_data {
+ /* Must be first in struct, we cast to vdso_data */
+ struct vdso_data data[CS_BASES];
+ struct vdso_cpu_data cpu_data[];
+};
+
+#ifdef __VDSO__
+static inline struct vdso_cpu_data *__vdso_cpu_data(void)
+{
+ unsigned long offset;
+
+ asm volatile(
+ "mrs %0, tpidrro_el0\n"
+ : "=r" (offset)
+ :
+ : "cc");
+
+ if (offset)
+ return (void *)(_vdso_data) + offset;
+
+ return NULL;
+}
+#else
+static inline size_t vdso_cpu_offset(void)
+{
+ size_t offset, data_end;
+
+ offset = offsetof(struct arm64_vdso_data, cpu_data) +
+ smp_processor_id() * sizeof(struct vdso_cpu_data);
+ data_end = offset + sizeof(struct vdso_cpu_data) + 1;
+
+ /* We only map a single page for vDSO data currently */
+ if (data_end > PAGE_SIZE)
+ return 0;
+
+ return offset;
+}
+#endif
+
+#endif
diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
index 6089638c7d43..b37fe0ceb1c9 100644
--- a/arch/arm64/kernel/process.c
+++ b/arch/arm64/kernel/process.c
@@ -55,6 +55,7 @@
#include <asm/processor.h>
#include <asm/pointer_auth.h>
#include <asm/stacktrace.h>
+#include <asm/vdso/datapage.h>
#if defined(CONFIG_STACKPROTECTOR) && !defined(CONFIG_STACKPROTECTOR_PER_TASK)
#include <linux/stackprotector.h>
@@ -309,6 +310,28 @@ void show_regs(struct pt_regs * regs)
dump_backtrace(regs, NULL, KERN_DEFAULT);
}
+void start_thread(struct pt_regs *regs, unsigned long pc, unsigned long sp)
+{
+ start_thread_common(regs, pc);
+ regs->pstate = PSR_MODE_EL0t;
+
+ if (arm64_get_ssbd_state() != ARM64_SSBD_FORCE_ENABLE)
+ set_ssbs_bit(regs);
+
+ regs->sp = sp;
+
+ /*
+ * Store the vDSO per-CPU offset if supported. Disable
+ * preemption to make sure we read the CPU offset on the CPU
+ * we write it on.
+ */
+ if (!arm64_kernel_unmapped_at_el0()) {
+ preempt_disable();
+ write_sysreg(vdso_cpu_offset(), tpidrro_el0);
+ preempt_enable();
+ }
+}
+
static void tls_thread_flush(void)
{
write_sysreg(0, tpidr_el0);
@@ -452,7 +475,8 @@ static void tls_thread_switch(struct task_struct *next)
if (is_compat_thread(task_thread_info(next)))
write_sysreg(next->thread.uw.tp_value, tpidrro_el0);
else if (!arm64_kernel_unmapped_at_el0())
- write_sysreg(0, tpidrro_el0);
+ /* Used as scratch in KPTI trampoline so don't set here. */
+ write_sysreg(vdso_cpu_offset(), tpidrro_el0);
write_sysreg(*task_user_tls(next), tpidr_el0);
}
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 4e016574bd91..ea5e18e37371 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -27,6 +27,7 @@
#include <asm/cacheflush.h>
#include <asm/signal32.h>
#include <asm/vdso.h>
+#include <asm/vdso/datapage.h>
extern char vdso_start[], vdso_end[];
#ifdef CONFIG_COMPAT_VDSO
@@ -70,10 +71,10 @@ static struct vdso_abi_info vdso_info[] __ro_after_init = {
* The vDSO data page.
*/
static union {
- struct vdso_data data[CS_BASES];
+ struct arm64_vdso_data data;
u8 page[PAGE_SIZE];
} vdso_data_store __page_aligned_data;
-struct vdso_data *vdso_data = vdso_data_store.data;
+struct vdso_data *vdso_data = vdso_data_store.data.data;
static int __vdso_remap(enum vdso_abi abi,
const struct vm_special_mapping *sm,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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