* [PATCH] tty/serial: atmel: use port->name as name in request_irq()
From: Richard Genoud @ 2018-05-03 15:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <921729c6-7c3f-11cd-8634-044a5c52f810@sorico.fr>
On 03/05/2018 15:34, Richard Genoud wrote:
> On 03/05/2018 14:44, Sebastian Andrzej Siewior wrote:
>> On 2018-05-03 14:36:03 [+0200], Richard Genoud wrote:
>>> Could resend your patch with Fixes: in the commit message ?
>>
>> will do shortly.
>>
>>> BTW, I didn't manage to reproduce the behavior you describe, could you
>>> give me your .config and describe a little more how you manage to
>>> trigger this bug ?
>> .config sent offlist.
>> Did you not reproduce this even with the second/debug patch I've sent?
> Nope. (I tried on a sam9g35 with buildroot/busybox)
>
> I have a sama5d3 with a debian as a home server, I'll give it a try.
Ok, I reproduced the use-after-free on a SAMA5D2 and on a SAMA5D3, both
with debian (sid / stretch).
After the patch, no mode funny things in /proc/interrupts.
>
>>
>>> (do you use the console on serial debug ? which board ? )
>> up to date debian sid booting with systemd. After boot completed I do
>> "cat /proc/interrupts" and check for the "gone" string.
>> This is
>> [ 0.000000] OF: fdt:Machine model: SAMA5D3 Xplained
>> [ 0.000000] Kernel command line: earlyprintk=ttyS0,115200 console=ttyS0,115200 root=/dev/mmcblk0p2 rootwait
>> [ 0.520000] AT91: Detected SoC family: sama5d3
>> [ 0.520000] AT91: Detected SoC: sama5d36, revision 2
>>
>> at91-sama5d3_xplained.dtb
>>
>> Is this enough?
>
> Great,
>
> Thanks !
>
^ permalink raw reply
* [PATCH] ARM: dts: cygnus: fix irq type for arm global timer
From: Florian Fainelli @ 2018-05-03 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503094445.324-1-peron.clem@gmail.com>
Hi Clement,
Adding Ray, Scott, Eric and bcm-kernel-feedback-list
On 05/03/2018 02:44 AM, Cl?ment P?ron wrote:
> As per ARM documentation
> PPI(0) ID27 - global timer interrupt is rising-edge sensitive.
>
> set IRQ triggering type to IRQ_TYPE_EDGE_RISING for ARM Global timers.
This looks right and consistent with what was done on other iProc
processors (BCM5301x, NSP etc.). Would you mind providing an appropriate
Fixes: tag such that this can get backported to stable trees as well?
Thanks!
>
> Signed-off-by: Cl?ment P?ron <peron.clem@gmail.com>
> ---
> arch/arm/boot/dts/bcm-cygnus.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi b/arch/arm/boot/dts/bcm-cygnus.dtsi
> index 699fdf94d139..9fe4f5a6379e 100644
> --- a/arch/arm/boot/dts/bcm-cygnus.dtsi
> +++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
> @@ -69,7 +69,7 @@
> timer at 20200 {
> compatible = "arm,cortex-a9-global-timer";
> reg = <0x20200 0x100>;
> - interrupts = <GIC_PPI 11 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_PPI 11 IRQ_TYPE_EDGE_RISING>;
> clocks = <&periph_clk>;
> };
>
>
--
Florian
^ permalink raw reply
* [PATCH 06/17] irqchip/irq-mvebu-icu: switch to regmap
From: Miquel Raynal @ 2018-05-03 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430155352.1b24d1d8@windsurf>
Hi Thomas, Gregory,
On Mon, 30 Apr 2018 15:53:52 +0200, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> On Sat, 21 Apr 2018 15:55:26 +0200, Miquel Raynal wrote:
> > The ICU DT nodes have now the 'syscon' compatible, we can switch to
>
> have now -> now have
>
> > regmap before splitting the code to support multiple platform devices to
> > be probed (one for the ICU, one per interrupt group).
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> As I explained in the review of PATCH 03/17, I think we could simply
> create the regmap in the ->probe() of the parent device, instead of
> using the "syscon" property, which is mainly useful when there is no
> parent device.
This is a much better idea than adding the 'syscon' compatible. I will
work on it.
>
> The rest of the conversion to regmap looks good otherwise.
>
> Best regards,
>
> Thomas
Thanks,
Miqu?l
--
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 1/2] regulator: dt-bindings: add QCOM RPMh regulator bindings
From: Doug Anderson @ 2018-05-03 15:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db8970ea-05f4-e7c0-52fa-070c7a6b8d2e@codeaurora.org>
Hi,
On Wed, May 2, 2018 at 5:13 PM, David Collins <collinsd@codeaurora.org> wrote:
> On 05/02/2018 09:37 AM, Doug Anderson wrote:
>> On Fri, Apr 13, 2018 at 7:50 PM, David Collins <collinsd@codeaurora.org> wrote:
>>> +- vdd_l26-supply
>>> +- vdd_lvs1_lvs2-supply
>>> +- vdd_lvs1_lvs2-supply
>>> + Usage: optional (PM8998 only)
>>> + Value type: <phandle>
>>> + Definition: phandle of the parent supply regulator of one or more of the
>>> + regulators for this PMIC.
>>
>> One small additional nit here is that "vdd_lvs1_lvs2-supply" is listed twice.
>
> I'll remove the duplicate.
>
>
>> Also on the schematics (and in the PM8998 datasheet) I have this is
>> "VIN_LVS_1_2". It seems like you should be consistent here and call
>> this "vin-lvs-1-2-supply".
>
> I was trying to keep the naming consistent within device tree binding
> documentation for LVS vs LDO and SMPS (e.g. 'vdd' vs 'vin' prefix). I
> suppose that I can change this to match the hardware documentation pin
> name. I can also change '_' to '-' in the supply names if that is preferred.
I'd rather it match the docs. I personally have no idea for why the
writer of the docs used "vdd" vs. "vin", but even if they had no good
reason matching the docs makes this searchable.
As far as the "_" to "-", Rob asked for that earlier in this thread
and you says "I will change this on the next patch set." In general
the desire to convert "_" to "-" makes this less searchable (since the
docs use "_"), but that's the way device tree guys want it so so c'est
la vie. Luckily it's easily to mentally change the "-"s back to "_"s
when searching...
-Doug
^ permalink raw reply
* [PATCH 0/3] ARM: dts: stm32: Add display support on stm32f469-disco
From: Alexandre Torgue @ 2018-05-03 14:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180215082014.30383-1-philippe.cornu@st.com>
Hi Philippe
On 02/15/2018 09:20 AM, Philippe Cornu wrote:
> This serie adds the mipi dsi support to stm32f469 and enables it
> on the stm32f469-disco board.
>
> Philippe CORNU (1):
> ARM: dts: stm32: Add display support on stm32f469-disco
>
> Philippe Cornu (2):
> ARM: dts: stm32: Add dt-bindings gpio.h include on stm32f469-disco
> ARM: dts: stm32: Add new stm32f469 dtsi file with mipi dsi
>
> arch/arm/boot/dts/stm32f469-disco.dts | 54 +++++++++++++++++++++++++++++++++--
> arch/arm/boot/dts/stm32f469.dtsi | 19 ++++++++++++
> 2 files changed, 71 insertions(+), 2 deletions(-)
> create mode 100644 arch/arm/boot/dts/stm32f469.dtsi
>
Thanks for new dtsi file. Series applied on stm32-next.
Regards
Alex
^ permalink raw reply
* [PATCH 04/17] irqchip/irq-mvebu-icu: fix wrong user data retrieval
From: Miquel Raynal @ 2018-05-03 14:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180430154913.64d94375@windsurf>
Hi Thomas,
On Mon, 30 Apr 2018 15:49:13 +0200, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello,
>
> In the title, I think "user data" is not really appropriate. "private
> date" or "device private data" maybe ?
Sure, I will change to "fix wrong private data retrieval".
>
> On Sat, 21 Apr 2018 15:55:24 +0200, Miquel Raynal wrote:
> > The irq_domain structure has an host_data pointer that just stores user
> > data. It is meant to not be touched by the IRQ core. However, when it
> > comes to MSI, the MSI layer adds its own private data there with a
> > structure that also has a host_data pointer.
> >
> > Because this IRQ domain is an MSI domain, to access user data we should
> > do a d->host_data->host_data, also wrapped as
> > 'platform_msi_get_host_data()'.
> >
> > This bug was lying there silently because the 'icu' structure retrieved
> > this way was just called by dev_err(), only producing a
> > '(NULL device *):' output on the console.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
>
> Otherwise:
>
> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Thanks,
Miqu?l
--
Miquel Raynal, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v14 8/8] ASoC: sun4i-codec: Add Left Capture Select, Right Capture Select
From: Maxime Ripard @ 2018-05-03 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502210800.1971-9-dannym@scratchpost.org>
Hi,
On Wed, May 02, 2018 at 11:08:00PM +0200, Danny Milosavljevic wrote:
> Add Left Capture Select and Right Capture Select for Allwinner A10 and
> Allwinner A20.
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 50 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 45dcb80a1da9..1a4ba3bae5da 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -706,6 +706,25 @@ static DECLARE_TLV_DB_RANGE(sun7i_codec_micin_preamp_gain_scale,
> 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0));
>
> +static const char * const sun4i_codec_capture_source[] = {
> + "Line",
> + "FM",
> + "Mic1",
> + "Mic2",
> + "Mic1,Mic2",
> + "Mic1+Mic2",
> + "Output Mixer",
> + "Line,Mic1",
> +};
Shouldn't that be defined in a more generic way? As far as I know,
there's no way to tell what the difference between "Mic1,Mic2" and
"Mic1+Mic2" would be from the userspace.
I guess the larger issue is that you'd need to have controls that are
common to both channels (ie that would change the routing of both
mixers), but aren't sharing the same controls structure since the
label would be different.
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/12a3203c/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: debug: enable UART1 for socfpga Cyclone5
From: Clément Péron @ 2018-05-03 14:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4da58449-af42-827c-09ff-6789e78f8e97@kernel.org>
Hi Dinh,
On Thu, 3 May 2018 at 16:32, Dinh Nguyen <dinguyen@kernel.org> wrote:
> Do you have a Cyclone5/Arria5 board that is using UART1 for the debug
port?
> Dinh
Yes I have a Cyclone5 board where the debug serial port used is UART1,
Clement
^ permalink raw reply
* [PATCH v14 3/8] ASoC: sun4i-codec: Merge sun4i_codec_left_mixer_controls and sun4i_codec_right_mixer_controls into sun4i_codec_mixer_controls
From: Maxime Ripard @ 2018-05-03 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502210800.1971-4-dannym@scratchpost.org>
On Wed, May 02, 2018 at 11:07:55PM +0200, Danny Milosavljevic wrote:
> Since it's now possible to have a DAPM mixer control with multiple channels,
> use it to cut down the total number of controls.
>
> Keep "Left Mixer Left DAC Playback Switch" and "Right Mixer Right DAC Playback
> Switch" name & layout the same as before for compatibility.
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 32 ++++++++++++++++----------------
> 1 file changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 4af286f44a67..b62af407967f 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -715,15 +715,15 @@ static const struct snd_kcontrol_new sun7i_codec_extra_controls[] = {
> sun7i_codec_micin_preamp_gain_scale),
> };
>
> -static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
> - SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
> - SUN4I_CODEC_DAC_ACTL_LDACLMIXS, 1, 0),
> -};
> -
> -static const struct snd_kcontrol_new sun4i_codec_right_mixer_controls[] = {
> - SOC_DAPM_SINGLE("Right DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
> - SUN4I_CODEC_DAC_ACTL_RDACRMIXS, 1, 0),
> - SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
> +static const struct snd_kcontrol_new sun4i_codec_mixer_controls[] = {
> + SOC_DAPM_SINGLE("Left Mixer Left DAC Playback Switch",
> + SUN4I_CODEC_DAC_ACTL, SUN4I_CODEC_DAC_ACTL_LDACLMIXS,
> + 1, 0),
> + SOC_DAPM_SINGLE("Right Mixer Right DAC Playback Switch",
> + SUN4I_CODEC_DAC_ACTL, SUN4I_CODEC_DAC_ACTL_RDACRMIXS,
> + 1, 0),
> + SOC_DAPM_SINGLE("Right Mixer Left DAC Playback Switch",
> + SUN4I_CODEC_DAC_ACTL,
> SUN4I_CODEC_DAC_ACTL_LDACRMIXS, 1, 0),
> };
>
> @@ -759,11 +759,11 @@ static const struct snd_soc_dapm_widget sun4i_codec_codec_dapm_widgets[] = {
>
> /* Mixers */
> SND_SOC_DAPM_MIXER("Left Mixer", SND_SOC_NOPM, 0, 0,
> - sun4i_codec_left_mixer_controls,
> - ARRAY_SIZE(sun4i_codec_left_mixer_controls)),
> + sun4i_codec_mixer_controls,
> + ARRAY_SIZE(sun4i_codec_mixer_controls)),
> SND_SOC_DAPM_MIXER("Right Mixer", SND_SOC_NOPM, 0, 0,
> - sun4i_codec_right_mixer_controls,
> - ARRAY_SIZE(sun4i_codec_right_mixer_controls)),
> + sun4i_codec_mixer_controls,
> + ARRAY_SIZE(sun4i_codec_mixer_controls)),
Doesn't that mean that the controls will be shared between the right
and left mixers now, which wasn't the case before? And also, wouldn't
the controls be called "Left Mixer Left Mixer Left DAC Playback
Switch" (for the first one) now?
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/12d5896a/attachment.sig>
^ permalink raw reply
* [PATCH v2 05/17] arm64: Helper for parange to PASize
From: James Morse @ 2018-05-03 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1522156531-28348-6-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
Nit: KVM in the subject line?
On 27/03/18 14:15, Suzuki K Poulose wrote:
> Add a helper to convert ID_AA64MMFR0_EL1:PARange to they physical
> size shift. Limit the size to the maximum supported by the kernel.
> We are about to move the user of this code and this helps to
> keep the changes cleaner.
> diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
> index fbf0aab..1f2a5dd 100644
> --- a/arch/arm64/include/asm/cpufeature.h
> +++ b/arch/arm64/include/asm/cpufeature.h
> @@ -311,6 +311,22 @@ static inline u64 read_zcr_features(void)
> return zcr;
> }
>
> +static inline u32 id_aa64mmfr0_parange_to_phys_shift(int parange)
> +{
> + switch (parange) {
> + case 0: return 32;
> + case 1: return 36;
> + case 2: return 40;
> + case 3: return 42;
> + case 4: return 44;
> + /* Report 48 bit if the kernel doesn't support 52bit */
> + default:
> + case 5: return 48;
> +#ifdef CONFIG_ARM64_PA_BITS_52
> + case 6: return 52;
> +#endif
Eeew. I thought 'default' had to appear at the end of the list, but evidently
not! If the last three bit value ever gets used this is going to look really weird.
Can't we have a helper that just does the mapping, then apply the clamping with
something like:
| parange = min(CONFIG_ARM64_PA_BITS, parange);
Its odd that the helper has the id-register in the name, but expects you do the
shift and mask for it...
(and for this patch, KVM has already done the 52bit clamping with:
| if (parange > ID_AA64MMFR0_PARANGE_MAX)
| parange = ID_AA64MMFR0_PARANGE_MAX;
)
> diff --git a/arch/arm64/kvm/hyp/s2-setup.c b/arch/arm64/kvm/hyp/s2-setup.c
> index 603e1ee..b1129c8 100644
> --- a/arch/arm64/kvm/hyp/s2-setup.c
> +++ b/arch/arm64/kvm/hyp/s2-setup.c
> @@ -19,11 +19,13 @@
> #include <asm/kvm_arm.h>
> #include <asm/kvm_asm.h>
> #include <asm/kvm_hyp.h>
> +#include <asm/cpufeature.h>
>
> u32 __hyp_text __init_stage2_translation(void)
> {
Nit: Why change the variable you put this in, if its all removed again in patch 11?
Thanks,
James
^ permalink raw reply
* [PATCH v2 11/17] kvm: arm64: Configure VTCR per VM
From: James Morse @ 2018-05-03 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1522156531-28348-12-git-send-email-suzuki.poulose@arm.com>
Hi Suzuki,
On 27/03/18 14:15, Suzuki K Poulose wrote:
> We set VTCR_EL2 very early during the stage2 init and don't
> touch it ever. This is fine as we had a fixed IPA size. This
> patch changes the behavior to set the VTCR for a given VM,
> depending on its stage2 table. The common configuration for
> VTCR is still performed during the early init as we have to
> retain the hardware access flag update bits (VTCR_EL2_HA)
> per CPU (as they are only set for the CPUs which are capabile).
> The bits defining the number of levels in the page table (SL0)
> and and the size of the Input address to the translation (T0SZ)
> are programmed for each VM upon entry to the guest.
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 596f8e4..9f3c8b8 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -392,10 +392,12 @@ int kvm_arm_vcpu_arch_has_attr(struct kvm_vcpu *vcpu,
>
> static inline void __cpu_init_stage2(void)
> {
> - u32 parange = kvm_call_hyp(__init_stage2_translation);
> + u32 ps;
>
> - WARN_ONCE(parange < 40,
> - "PARange is %d bits, unsupported configuration!", parange);
> + kvm_call_hyp(__init_stage2_translation);
> + ps = id_aa64mmfr0_parange_to_phys_shift(read_sysreg(id_aa64mmfr0_el1));
Doesn't id_aa64mmfr0_parange_to_phys_shift() expect you do to the mask and shift
for it? This will always hit the default case.
> + WARN_ONCE(ps < 40,
> + "PARange is %d bits, unsupported configuration!", ps);
> }
Thanks,
James
^ permalink raw reply
* [PATCH v2] drm/pl111: Fix module probe bug
From: Sean Paul @ 2018-05-03 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503140431.5798-1-linus.walleij@linaro.org>
On Thu, May 03, 2018 at 04:04:31PM +0200, Linus Walleij wrote:
> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
> Added a second module using the builtin_platform_driver() call,
> which works fine as long as you do not try to build the PL111
> driver as a module, because a module can only have one initcall
> and cause the following build bug:
>
> (...) multiple definition of `init_module' (...)
>
> Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: Liviu Dudau <liviu.dudau@arm.com>
> Cc: Pawel Moll <pawel.moll@arm.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> ChangeLog v1->v2:
> - In my stress I missed that if there are several CLCD instances
> on the board the platform_driver_register() call will return
> -EBUSY so we need to ignore that explicitly, all we want is to
> register the driver at least once.
> ---
> drivers/gpu/drm/pl111/pl111_versatile.c | 7 +++++++
> drivers/gpu/drm/pl111/pl111_vexpress.c | 12 ++++++++++--
> drivers/gpu/drm/pl111/pl111_vexpress.h | 7 +++++++
> 3 files changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c b/drivers/gpu/drm/pl111/pl111_versatile.c
> index 78ddf8534fd2..ad769e3e9fd3 100644
> --- a/drivers/gpu/drm/pl111/pl111_versatile.c
> +++ b/drivers/gpu/drm/pl111/pl111_versatile.c
> @@ -326,6 +326,13 @@ int pl111_versatile_init(struct device *dev, struct pl111_drm_dev_private *priv)
> if (versatile_clcd_type == VEXPRESS_CLCD_V2M) {
> struct platform_device *pdev;
>
> + /* Registers a driver for the muxfpga */
> + ret = vexpress_muxfpga_init();
> + if (ret) {
> + dev_err(dev, "unable to intialize muxfpga driver\n");
> + return ret;
> + }
> +
> /* Call into deep Vexpress configuration API */
> pdev = of_find_device_by_node(np);
> if (!pdev) {
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.c b/drivers/gpu/drm/pl111/pl111_vexpress.c
> index c9fee625faf1..c30f63cd66a8 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.c
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.c
> @@ -106,7 +106,6 @@ static int vexpress_muxfpga_probe(struct platform_device *pdev)
> if (IS_ERR(map))
> return PTR_ERR(map);
> dev_set_drvdata(dev, map);
> -
nit: unrelated whitespace change
> return 0;
> }
>
> @@ -122,4 +121,13 @@ static struct platform_driver vexpress_muxfpga_driver = {
> .probe = vexpress_muxfpga_probe,
> };
>
> -builtin_platform_driver(vexpress_muxfpga_driver);
> +int vexpress_muxfpga_init(void)
> +{
> + int ret;
> +
> + ret = platform_driver_register(&vexpress_muxfpga_driver);
> + /* -EBUSY just means this driver is already registered */
> + if (ret && ret != -EBUSY)
> + return ret;
> + return 0;
fwiw, i think it'd be cleaner to do:
/* -EBUSY just means this driver is already registered */
if (ret == -EBUSY)
ret = 0;
return ret;
or if you're one of those people who doesn't mind inline conditionals:
/* -EBUSY just means this driver is already registered */
return ret == -EBUSY ? 0 : ret;
Anyways, just verbalizing my personal code style. With the whitespace fix,
Reviewed-by: Sean Paul <seanpaul@chromium.org>
> +}
> diff --git a/drivers/gpu/drm/pl111/pl111_vexpress.h b/drivers/gpu/drm/pl111/pl111_vexpress.h
> index 49876417f7b6..40fbe42369dc 100644
> --- a/drivers/gpu/drm/pl111/pl111_vexpress.h
> +++ b/drivers/gpu/drm/pl111/pl111_vexpress.h
> @@ -10,6 +10,8 @@ int pl111_vexpress_clcd_init(struct device *dev,
> struct pl111_drm_dev_private *priv,
> struct regmap *map);
>
> +int vexpress_muxfpga_init(void);
> +
> #else
>
> static int inline pl111_vexpress_clcd_init(struct device *dev,
> @@ -19,4 +21,9 @@ static int inline pl111_vexpress_clcd_init(struct device *dev,
> return -ENODEV;
> }
>
> +static inline int vexpress_muxfpga_init(void)
> +{
> + return 0;
> +}
> +
> #endif
> --
> 2.17.0
>
--
Sean Paul, Software Engineer, Google / Chromium OS
^ permalink raw reply
* [PATCH v14 2/8] ASoC: sun4i-codec: Add Mic1 Boost Volume, Mic2 Boost Volume
From: Maxime Ripard @ 2018-05-03 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502210800.1971-3-dannym@scratchpost.org>
On Wed, May 02, 2018 at 11:07:54PM +0200, Danny Milosavljevic wrote:
> Add Mic1 Boost Volume and Mic2 Boost Volume for Allwinner A10 and Allwinner
> A20. Also add support for extra controls to the sun4i_codec_quirks because
> the A10 and A20 have Mic1 Boost Volume at different places (likewise for
> Mic2 Boost Volume).
A good rule of thumb is that when you have "also" in your commit log,
you should do another patch instead doing that instead.
>
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 66 ++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 56 insertions(+), 10 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 060a40b45ab0..4af286f44a67 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -95,6 +95,8 @@
> #define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
> #define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
> #define SUN4I_CODEC_ADC_ACTL_VMICEN (27)
> +#define SUN4I_CODEC_ADC_ACTL_PREG1 (25)
> +#define SUN4I_CODEC_ADC_ACTL_PREG2 (23)
> #define SUN4I_CODEC_ADC_ACTL_VADCG (20)
> #define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
> #define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
> @@ -111,6 +113,9 @@
> /* Microphone controls (sun7i only) */
> #define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1 (29)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2 (26)
> +
> /*
> * sun6i specific registers
> *
> @@ -676,6 +681,12 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
> static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale, -450, 150,
> 0);
> +static DECLARE_TLV_DB_RANGE(sun4i_codec_micin_preamp_gain_scale,
> + 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> + 1, 7, TLV_DB_SCALE_ITEM(3500, 300, 0));
> +static DECLARE_TLV_DB_RANGE(sun7i_codec_micin_preamp_gain_scale,
> + 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> + 1, 7, TLV_DB_SCALE_ITEM(2400, 300, 0));
>
> static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> @@ -686,6 +697,24 @@ static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> sun4i_codec_micin_loopback_gain_scale),
> };
>
> +static const struct snd_kcontrol_new sun4i_codec_extra_controls[] = {
> + SOC_SINGLE_TLV("Mic1 Boost Volume", SUN4I_CODEC_ADC_ACTL,
> + SUN4I_CODEC_ADC_ACTL_PREG1, 3, 0,
> + sun4i_codec_micin_preamp_gain_scale),
> + SOC_SINGLE_TLV("Mic2 Boost Volume", SUN4I_CODEC_ADC_ACTL,
> + SUN4I_CODEC_ADC_ACTL_PREG2, 3, 0,
> + sun4i_codec_micin_preamp_gain_scale),
> +};
> +
> +static const struct snd_kcontrol_new sun7i_codec_extra_controls[] = {
> + SOC_SINGLE_TLV("Mic1 Boost Volume", SUN7I_CODEC_AC_MIC_PHONE_CAL,
> + SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1, 7, 0,
> + sun7i_codec_micin_preamp_gain_scale),
> + SOC_SINGLE_TLV("Mic2 Boost Volume", SUN7I_CODEC_AC_MIC_PHONE_CAL,
> + SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2, 7, 0,
> + sun7i_codec_micin_preamp_gain_scale),
> +};
> +
> static const struct snd_kcontrol_new sun4i_codec_left_mixer_controls[] = {
> SOC_DAPM_SINGLE("Left DAC Playback Switch", SUN4I_CODEC_DAC_ACTL,
> SUN4I_CODEC_DAC_ACTL_LDACLMIXS, 1, 0),
> @@ -807,7 +836,30 @@ static const struct snd_soc_dapm_route sun4i_codec_codec_dapm_routes[] = {
> { "Mic2", NULL, "VMIC" },
> };
>
> +struct sun4i_codec_quirks {
> + const struct regmap_config *regmap_config;
> + const struct snd_soc_component_driver *codec;
> + struct snd_soc_card * (*create_card)(struct device *dev);
> + struct reg_field reg_adc_fifoc; /* used for regmap_field */
> + unsigned int reg_dac_txdata; /* TX FIFO offset for DMA config */
> + unsigned int reg_adc_rxdata; /* RX FIFO offset for DMA config */
> + bool has_reset;
> + const struct snd_kcontrol_new *controls;
> + unsigned int num_controls;
> +};
> +
> +static int sun4i_codec_component_driver_probe(struct snd_soc_component *codec)
> +{
> + const struct sun4i_codec_quirks *quirks;
> +
> + quirks = of_device_get_match_data(codec->dev);
> + return snd_soc_add_component_controls(codec,
> + quirks->controls,
> + quirks->num_controls);
Why not just extending the sun4i_codec_controls to add it, and create
a duplicate one for the A20?
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/c2b34e1c/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: debug: enable UART1 for socfpga Cyclone5
From: Dinh Nguyen @ 2018-05-03 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503121342.14178-1-peron.clem@gmail.com>
Hi Cl?ment,
On 05/03/2018 07:13 AM, Cl?ment P?ron wrote:
> Cyclone5 and Arria10 doesn't have the same memory map for UART1.
>
> Split the SOCFPGA_UART1 into 2 options to allow debugging on UART1 for Cylone5.
>
Do you have a Cyclone5/Arria5 board that is using UART1 for the debug port?
Dinh
^ permalink raw reply
* [PATCH v14 1/8] ASoC: sun4i-codec: Add MIC2 Pre-Amplifier, Mic2, Mic Playback Volume
From: Maxime Ripard @ 2018-05-03 14:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180502210800.1971-2-dannym@scratchpost.org>
On Wed, May 02, 2018 at 11:07:53PM +0200, Danny Milosavljevic wrote:
> Add MIC2 Pre-Amplifier, Mic2 input and Mic Playback Volume for Allwinner A10
> and Allwinner A20.
That's a general remark for all your commits here, but you should have
more context in your commit logs, for example to define what is the
usual use case for these microphones, if the playback volume applies
to all mic at once, or just a fraction of them, etc.
> Signed-off-by: Danny Milosavljevic <dannym@scratchpost.org>
> ---
> sound/soc/sunxi/sun4i-codec.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 9a3cb7704810..060a40b45ab0 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -64,6 +64,7 @@
> #define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
> #define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
> #define SUN4I_CODEC_DAC_ACTL_MIXEN (29)
> +#define SUN4I_CODEC_DAC_ACTL_MICG (20)
> #define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
> #define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
> #define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
> @@ -673,11 +674,16 @@ static const struct snd_kcontrol_new sun4i_codec_pa_mute =
> SUN4I_CODEC_DAC_ACTL_PA_MUTE, 1, 0);
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale, -450, 150,
> + 0);
>
> static const struct snd_kcontrol_new sun4i_codec_controls[] = {
> SOC_SINGLE_TLV("Power Amplifier Volume", SUN4I_CODEC_DAC_ACTL,
> SUN4I_CODEC_DAC_ACTL_PA_VOL, 0x3F, 0,
> sun4i_codec_pa_volume_scale),
> + SOC_SINGLE_TLV("Mic Playback Volume", SUN4I_CODEC_DAC_ACTL,
> + SUN4I_CODEC_DAC_ACTL_MICG, 7, 0,
> + sun4i_codec_micin_loopback_gain_scale),
This should probably go in a separate patch, it isn't directly related
to the rest of the patch.
Looks good otherwise, thanks!
Maxime
--
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180503/165ebe99/attachment-0001.sig>
^ permalink raw reply
* Motorola Droid 4 progress, power consumption
From: Tony Lindgren @ 2018-05-03 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503090611.GA14451@amd>
* Pavel Machek <pavel@ucw.cz> [180503 09:08]:
> I'd like current_avg more, but if I cat it manually, it changes on
> order of seconds, and quite significantly... which suggest shorter
> polling interval would be needed.
>
> user at devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May 3 09:33:05 CEST 2018
> -71000
> -218408
> user at devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May 3 09:33:06 CEST 2018
> -61000
> -200238
> user at devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May 3 09:33:06 CEST 2018
> -51000
> -209879
> user at devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May 3 09:33:07 CEST 2018
> -56000
> -72308
> user at devuan:/sys/class/power_supply/battery$ date; cat current_now
> current_avg
> Thu May 3 09:33:08 CEST 2018
> -37000
> -211362
I recall it just being calculated based on the time between
the reads. Hard to say what it does, -ENODOCS.. Maybe the mc13783
PMIC docs have something similar.
> > Hmm oh and the POWER_SUPPLY_CHARGE_COUNTER value should be monitored
> > by your libbattery and it's low value and high value should be saved
> > to a file. Low should be saved when we get the battery low interrupt
> > and battery state changes to POWER_SUPPLY_CAPACITY_LEVEL_CRITICAL.
> > High value should be saved on POWER_SUPPLY_CAPACITY_LEVEL_FULL.
> >
> > Then when you know the high value and low value, you can calculate
> > the remaining capacity based on the current value and
> > POWER_SUPPLY_POWER_AVG.
>
> I'll look into that... but probably will do experiments with python,
> first.
Sure. The reason why I think we should not do it in the kernel in
addition to the earlier reasoning is that we don't have a place
to store the min and max values across reboot. I think there's
some flash on the battery over 1w bus, but it probably just
contains battery serial number or something and is not intended
for writing much to it. I guess the min and max values should be
really keyd based on this battery id in case the battery gets
changed.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 6/6] arm64: update Documentation/arm64/tagged-pointers.txt
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
Add a note that work on passing tagged user pointers to the kernel via
syscalls has started, but might not be complete yet.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
Documentation/arm64/tagged-pointers.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/arm64/tagged-pointers.txt b/Documentation/arm64/tagged-pointers.txt
index a25a99e82bb1..361481283f00 100644
--- a/Documentation/arm64/tagged-pointers.txt
+++ b/Documentation/arm64/tagged-pointers.txt
@@ -35,8 +35,9 @@ Using non-zero address tags in any of these locations may result in an
error code being returned, a (fatal) signal being raised, or other modes
of failure.
-For these reasons, passing non-zero address tags to the kernel via
-system calls is forbidden, and using a non-zero address tag for sp is
+Some initial work for supporting non-zero address tags passed to the
+kernel via system calls has been done, but the kernel doesn't provide
+any guarantees at this point. Using a non-zero address tag for sp is
strongly discouraged.
Programs maintaining a frame pointer and frame records that use non-zero
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 5/6] lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
strncpy_from_user and strnlen_user accept user addresses as arguments, and
do not go through the same path as copy_from_user and others, so here we
need to handle the case of tagged user addresses separately.
Untag user pointers passed to these functions.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/lib/strncpy_from_user.c b/lib/strncpy_from_user.c
index b53e1b5d80f4..97467cd2bc59 100644
--- a/lib/strncpy_from_user.c
+++ b/lib/strncpy_from_user.c
@@ -106,6 +106,8 @@ long strncpy_from_user(char *dst, const char __user *src, long count)
if (unlikely(count <= 0))
return 0;
+ src = untagged_addr(src);
+
max_addr = user_addr_max();
src_addr = (unsigned long)src;
if (likely(src_addr < max_addr)) {
diff --git a/lib/strnlen_user.c b/lib/strnlen_user.c
index 60d0bbda8f5e..8b5f56466e00 100644
--- a/lib/strnlen_user.c
+++ b/lib/strnlen_user.c
@@ -108,6 +108,8 @@ long strnlen_user(const char __user *str, long count)
if (unlikely(count <= 0))
return 0;
+ str = untagged_addr(str);
+
max_addr = user_addr_max();
src_addr = (unsigned long)str;
if (likely(src_addr < max_addr)) {
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
mm/gup.c provides a kernel interface that accepts user addresses and
manipulates user pages directly (for example get_user_pages, that is used
by the futex syscall). Here we also need to handle the case of tagged user
pointers.
Add untagging to gup.c functions that use user pointers for vma lookup.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
mm/gup.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/mm/gup.c b/mm/gup.c
index 76af4cfeaf68..65a9566c96d3 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -647,6 +647,8 @@ static long __get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
if (!nr_pages)
return 0;
+ start = untagged_addr(start);
+
VM_BUG_ON(!!pages != !!(gup_flags & FOLL_GET));
/*
@@ -801,6 +803,8 @@ int fixup_user_fault(struct task_struct *tsk, struct mm_struct *mm,
struct vm_area_struct *vma;
int ret, major = 0;
+ address = untagged_addr(address);
+
if (unlocked)
fault_flags |= FAULT_FLAG_ALLOW_RETRY;
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 3/6] arm64: untag user addresses in access_ok and __uaccess_mask_ptr
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
copy_from_user (and a few other similar functions) are used to copy data
from user memory into the kernel memory or vice versa. Since a user can
provided a tagged pointer to one of the syscalls that use copy_from_user,
we need to correctly handle such pointers.
Do this by untagging user pointers in access_ok and in __uaccess_mask_ptr,
before performing access validity checks.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index 2d6451cbaa86..fa7318d3d7d5 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -105,7 +105,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
#define untagged_addr(addr) \
((__typeof__(addr))sign_extend64((__u64)(addr), 55))
-#define access_ok(type, addr, size) __range_ok(addr, size)
+#define access_ok(type, addr, size) \
+ __range_ok(untagged_addr(addr), size)
#define user_addr_max get_fs
#define _ASM_EXTABLE(from, to) \
@@ -237,7 +238,8 @@ static inline void uaccess_enable_not_uao(void)
/*
* Sanitise a uaccess pointer such that it becomes NULL if above the
- * current addr_limit.
+ * current addr_limit. In case the pointer is tagged (has the top byte set),
+ * untag the pointer before checking.
*/
#define uaccess_mask_ptr(ptr) (__typeof__(ptr))__uaccess_mask_ptr(ptr)
static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
@@ -245,10 +247,11 @@ static inline void __user *__uaccess_mask_ptr(const void __user *ptr)
void __user *safe_ptr;
asm volatile(
- " bics xzr, %1, %2\n"
+ " bics xzr, %3, %2\n"
" csel %0, %1, xzr, eq\n"
: "=&r" (safe_ptr)
- : "r" (ptr), "r" (current_thread_info()->addr_limit)
+ : "r" (ptr), "r" (current_thread_info()->addr_limit),
+ "r" (untagged_addr(ptr))
: "cc");
csdb();
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 2/6] uaccess: add untagged_addr definition for other arches
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
To allow arm64 syscalls accept tagged pointers from userspace, we must
untag them when they are passed to the kernel. Since untagging is done in
generic parts of the kernel (like the mm subsystem), the untagged_addr
macro should be defined for all architectures.
Define it as a noop for other architectures besides arm64.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
include/linux/uaccess.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/linux/uaccess.h b/include/linux/uaccess.h
index efe79c1cdd47..c045b4eff95e 100644
--- a/include/linux/uaccess.h
+++ b/include/linux/uaccess.h
@@ -13,6 +13,10 @@
#include <asm/uaccess.h>
+#ifndef untagged_addr
+#define untagged_addr(addr) addr
+#endif
+
/*
* Architectures should provide two primitives (raw_copy_{to,from}_user())
* and get rid of their private instances of copy_{to,from}_user() and
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 1/6] arm64: add type casts to untagged_addr macro
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1525356769.git.andreyknvl@google.com>
This patch makes the untagged_addr macro accept all kinds of address types
(void *, unsigned long, etc.) and allows not to specify type casts in each
place where it is used. This is done by using __typeof__.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
---
arch/arm64/include/asm/uaccess.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/uaccess.h b/arch/arm64/include/asm/uaccess.h
index e66b0fca99c2..2d6451cbaa86 100644
--- a/arch/arm64/include/asm/uaccess.h
+++ b/arch/arm64/include/asm/uaccess.h
@@ -102,7 +102,8 @@ static inline unsigned long __range_ok(const void __user *addr, unsigned long si
* up with a tagged userland pointer. Clear the tag to get a sane pointer to
* pass on to access_ok(), for instance.
*/
-#define untagged_addr(addr) sign_extend64(addr, 55)
+#define untagged_addr(addr) \
+ ((__typeof__(addr))sign_extend64((__u64)(addr), 55))
#define access_ok(type, addr, size) __range_ok(addr, size)
#define user_addr_max get_fs
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH v2 0/6] arm64: untag user pointers passed to the kernel
From: Andrey Konovalov @ 2018-05-03 14:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi!
arm64 has a feature called Top Byte Ignore, which allows to embed pointer
tags into the top byte of each pointer. Userspace programs (such as
HWASan, a memory debugging tool [1]) might use this feature and pass
tagged user pointers to the kernel through syscalls or other interfaces.
This patch makes a few of the kernel interfaces accept tagged user
pointers. The kernel is already able to handle user faults with tagged
pointers and has the untagged_addr macro, which this patchset reuses.
We're not trying to cover all possible ways the kernel accepts user
pointers in one patchset, so this one should be considered as a start.
Thanks!
[1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
Changes in v2:
- Rebased onto 2d618bdf (4.17-rc3+).
- Removed excessive untagging in gup.c.
- Removed untagging pointers returned from __uaccess_mask_ptr.
Changes in v1:
- Rebased onto 4.17-rc1.
Changes in RFC v2:
- Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of
defining it for each arch individually.
- Updated Documentation/arm64/tagged-pointers.txt.
- Dropped ?mm, arm64: untag user addresses in memory syscalls?.
- Rebased onto 3eb2ce82 (4.16-rc7).
Andrey Konovalov (6):
arm64: add type casts to untagged_addr macro
uaccess: add untagged_addr definition for other arches
arm64: untag user addresses in access_ok and __uaccess_mask_ptr
mm, arm64: untag user addresses in mm/gup.c
lib, arm64: untag addrs passed to strncpy_from_user and strnlen_user
arm64: update Documentation/arm64/tagged-pointers.txt
Documentation/arm64/tagged-pointers.txt | 5 +++--
arch/arm64/include/asm/uaccess.h | 14 +++++++++-----
include/linux/uaccess.h | 4 ++++
lib/strncpy_from_user.c | 2 ++
lib/strnlen_user.c | 2 ++
mm/gup.c | 4 ++++
6 files changed, 24 insertions(+), 7 deletions(-)
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply
* [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
From: Andrey Konovalov @ 2018-05-03 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAAeHK+yTbmZfkeNbqbo+J90zsjsM99rwnYBGfQBxphHMMfgD7A@mail.gmail.com>
On Wed, May 2, 2018 at 7:25 PM, Andrey Konovalov <andreyknvl@google.com> wrote:
> On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov
> <kirill.shutemov@linux.intel.com> wrote:
>> On Wed, May 02, 2018 at 02:38:42PM +0000, Andrey Konovalov wrote:
>>> > Does having a tagged address here makes any difference? I couldn't hit a
>>> > failure with my simple tests (LD_PRELOAD a library that randomly adds
>>> > tags to pointers returned by malloc).
>>>
>>> I think you're right, follow_page_mask is only called from
>>> __get_user_pages, which already untagged the address. I'll remove
>>> untagging here.
>>
>> It also called from follow_page(). Have you covered all its callers?
>
> Oh, missed that, will take a look.
I wasn't able to find anything that calls follow_page with pointers
passed from userspace except for the memory subsystem syscalls, and we
deliberately don't add untagging in those.
^ permalink raw reply
* [PATCH] drm/pl111: Fix module probe bug
From: Linus Walleij @ 2018-05-03 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180503134312.GN12521@phenom.ffwll.local>
On Thu, May 3, 2018 at 3:43 PM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Thu, May 03, 2018 at 03:40:53PM +0200, Linus Walleij wrote:
>> Commit a30933c27602 ("drm/pl111: Support the Versatile Express")
>> Added a second module using the builtin_platform_driver() call,
>> which works fine as long as you do not try to build the PL111
>> driver as a module, because a module can only have one initcall
>> and cause the following build bug:
>>
>> (...) multiple definition of `init_module' (...)
>>
>> Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> Cc: Liviu Dudau <liviu.dudau@arm.com>
>> Cc: Pawel Moll <pawel.moll@arm.com>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Robin Murphy <robin.murphy@arm.com>
>> Fixes: a30933c27602 ("drm/pl111: Support the Versatile Express")
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>
> lgtm. Please also reenable the pl111 driver in the drm-rerere branch, you
> can simple revert 17c11b73c2ea6a21eaad5c1f5d358054c9e2c2f6.
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Thanks Daniel, hope I can count that Review tag for v2 as well.
Will apply and push later tonight unless I have done more mistakes.
Yours,
Linus Walleij
^ 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