* [PATCH 17/22] power: supply: add battery driver for AXP20X and AXP22X PMICs
From: Ezequiel Garcia @ 2017-01-05 17:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102163723.7939-18-quentin.schulz@free-electrons.com>
On 2 January 2017 at 13:37, Quentin Schulz
<quentin.schulz@free-electrons.com> wrote:
[...]
> +
> +#define AXP20X_PWR_STATUS_BAT_CHARGING BIT(2)
> +
> +#define AXP20X_PWR_OP_BATT_PRESENT BIT(5)
> +#define AXP20X_PWR_OP_BATT_ACTIVATED BIT(3)
> +
> +#define AXP209_FG_PERCENT GENMASK(6, 0)
> +#define AXP22X_FG_VALID BIT(7)
> +
> +#define AXP20X_CHRG_CTRL1_TGT_VOLT GENMASK(6, 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_1V (0 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_15V BIT(5)
This is just a silly nit, but I would put (1 << 5) here
for readability.
> +#define AXP20X_CHRG_CTRL1_TGT_4_2V (2 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_4_36V (3 << 5)
> +#define AXP20X_CHRG_CTRL1_TGT_CURR GENMASK(3, 0)
> +
> +#define AXP22X_CHRG_CTRL1_TGT_4_22V BIT(5)
Ditto.
> +#define AXP22X_CHRG_CTRL1_TGT_4_24V (3 << 5)
> +
> +#define AXP20X_V_OFF_MASK GENMASK(2, 0)
> +
> +struct axp20x_batt_ps {
> + struct regmap *regmap;
> + struct power_supply *batt;
> + struct axp20x_dev *axp20x;
> + struct iio_channel *batt_chrg_i;
> + struct iio_channel *batt_dischrg_i;
> + struct iio_channel *batt_v;
> + u8 axp_id;
> +};
> +
[..]
> +static int axp20x_power_probe(struct platform_device *pdev)
> +{
> + struct axp20x_dev *axp20x = dev_get_drvdata(pdev->dev.parent);
> + struct axp20x_batt_ps *axp20x_batt;
> + struct power_supply_config psy_cfg = {};
> +
To be consistent with the AC power supply and USB power supply,
you might want to call of_device_is_available() here.
Otherwise, the device probes even if "disabled" in the DTS.
> + axp20x_batt = devm_kzalloc(&pdev->dev, sizeof(*axp20x_batt),
> + GFP_KERNEL);
> + if (!axp20x_batt)
> + return -ENOMEM;
> +
Thanks for the good work,
--
Ezequiel Garc?a, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply
* [PATCH 1/3] ARM: OMAP1: USB: tidy up logging output
From: Tony Lindgren @ 2017-01-05 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170102205705.19001-1-aaro.koskinen@iki.fi>
* Aaro Koskinen <aaro.koskinen@iki.fi> [170102 12:58]:
> KERN_CONT/pr_cont is now required to continue log messages, use that.
Applying all into omap-for-v4.11/omap1 thanks.
Tony
^ permalink raw reply
* [PATCH 5/5] arm64: dts: add BananaPi-M64 support
From: Maxime Ripard @ 2017-01-05 17:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-6-git-send-email-andre.przywara@arm.com>
On Mon, Jan 02, 2017 at 11:03:46PM +0000, Andre Przywara wrote:
> The Banana Pi M64 board is a typical single board computer based on the
> Allwinner A64 SoC. Aside from the usual peripherals it features eMMC
> storage, which is connected to the 8-bit capable SDHC2 controller.
> Also it has a soldered WiFi/Bluetooth chip, so we enable UART1 and SDHC1
> as those two interfaces are connected to it.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 125 +++++++++++++++++++++
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 10 ++
> 3 files changed, 136 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 1e29a5a..51ecb04 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-bananapi-m64.dtb
Please sort it by alphabetical order.
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> new file mode 100644
> index 0000000..941ea07
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-bananapi-m64.dts
> @@ -0,0 +1,125 @@
> +/*
> + * Copyright (c) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This library is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This library is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-a64.dtsi"
> +
> +/ {
> + model = "BananaPi-M64";
> + compatible = "sinovoip,bananapi-m64", "allwinner,sun50i-a64";
> +
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +};
> +
> +&uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart0_pins_a>;
> + status = "okay";
> +};
> +
> +&uart1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart1_pins_4>;
> + status = "okay";
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1_pins>;
> + status = "okay";
> +};
And the nodes too.
> +
> +&i2c1_pins {
> + bias-pull-up;
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins>, <&mmc0_default_cd_pin>;
> + vmmc-supply = <®_vcc3v3>;
> + cd-gpios = <&pio 5 6 0>;
Please use a define here.
> + cd-inverted;
> + disable-wp;
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&mmc1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc1_pins>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + non-removable;
> + status = "okay";
> +};
> +
> +&mmc2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc2_pins>;
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <8>;
> + non-removable;
> + cap-mmc-hw-reset;
> + status = "okay";
> +};
> +
> +&mmc2_pins {
> + /* Increase drive strength for DDR modes */
> + drive-strength = <40>;
Allwinner recommends to use 30mA, have you tested it?
> + /* eMMC is missing pull-ups */
> + bias-pull-up;
This is the default now.
> +};
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index c680566..9de96ba 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -151,6 +151,16 @@
> function = "uart0";
> };
>
> + uart1_pins: uart1 at 0 {
> + pins = "PG6", "PG7";
> + function = "uart1";
> + };
> +
> + uart1_pins_4: uart1_4 at 0 {
> + pins = "PG6", "PG7", "PG8", "PG9";
For other nodes, we've been creating another node for the cts and rts
signals, and reference both nodes in the pinctrl properties. It allows
to avoid duplication.
> + function = "uart1";
> + };
> +
> mmc0_pins: mmc0 at 0 {
Please sort it by alphabetical order. And it should be in a separate
patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/90f999e6/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2017-01-05 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105171601.us4wffupptilvvqp@lukather>
Hi,
On Thu, 5 Jan 2017 18:16:01 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > connectors.
> >
> > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > ---
> > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > index 669a1c338c76..fa8c6f60552b 100644
> > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > @@ -300,12 +300,14 @@
> > pinctrl-names = "default";
> > pinctrl-0 = <&spi1_pins_a>,
> > <&spi1_cs0_pins_a>;
> > + status = "okay";
> > };
> >
> > &spi2 {
> > pinctrl-names = "default";
> > pinctrl-0 = <&spi2_pins_a>,
> > <&spi2_cs0_pins_a>;
> > + status = "okay";
> > };
>
> Those nodes don't exist unfortunately. Maybe you forgot to send one
> patch?
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
It's based on a previous sent patch :
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
You said you'll squash the two commits.
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH v2] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Jörg Krause @ 2017-01-05 17:37 UTC (permalink / raw)
To: linux-arm-kernel
The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi part
is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC also
takes a power enable signal via GPIO.
This commit adds a device-tree node to power it up, so the mmc subsys
can scan it, and enables the mmc controller which is connected to it.
As the wifi enable pin of the AP6181 module is not really a regulator,
switch the mmc3 node to the mmc-pwrseq framework for controlling it.
This more accurately reflectes how the hardware actually works.
Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
---
Changes v2 (suggested by Maxime Ripard):
- rename pwrseq node to clarify the function rather what it's
connected to
- use dash instead of underscore for the pwrseq node name
- remove setting pull-ups for mmc3 (default since commit 37bc56128d92)
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 30 ++++++++++++++++++------------
1 file changed, 18 insertions(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 19d63d4049de..77f8fb76c157 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -76,6 +76,13 @@
};
};
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-names = "default";
+ pinctrl-0 = <&vmmc3_pin_bananapro>;
+ reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
+ };
+
reg_gmac_3v3: gmac-3v3 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -87,17 +94,6 @@
enable-active-high;
gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
};
-
- reg_vmmc3: vmmc3 {
- compatible = "regulator-fixed";
- pinctrl-names = "default";
- pinctrl-0 = <&vmmc3_pin_bananapro>;
- regulator-name = "vmmc3";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- enable-active-high;
- gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
- };
};
&ahci {
@@ -166,10 +162,20 @@
&mmc3 {
pinctrl-names = "default";
pinctrl-0 = <&mmc3_pins_a>;
- vmmc-supply = <®_vmmc3>;
+ vmmc-supply = <®_vcc3v3>;
+ mmc-pwrseq = <&wifi_pwrseq>;
bus-width = <4>;
non-removable;
+ wakeup-source;
status = "okay";
+
+ brcmf: bcrmf at 1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ interrupt-parent = <&pio>;
+ interrupts = <7 15 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-names = "host-wake";
+ };
};
&ohci0 {
--
2.11.0
^ permalink raw reply related
* [RFC PATCH 4/7] KVM: arm/arm64: Check that system supports split eoi/deactivate
From: Marc Zyngier @ 2017-01-05 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210204712.21830-5-christoffer.dall@linaro.org>
On 10/12/16 20:47, Christoffer Dall wrote:
> Some systems without proper firmware and/or hardware description data
> don't support the split EOI and deactivate operation and therefore
> don't provide an irq_set_vcpu_affinity implementation. On such
> systems, we cannot leave the physical interrupt active after the timer
> handler on the host has run, so we cannot support KVM with the timer
> changes we about to introduce.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> virt/kvm/arm/arch_timer.c | 30 ++++++++++++++++++++++++++++++
> 1 file changed, 30 insertions(+)
>
> diff --git a/virt/kvm/arm/arch_timer.c b/virt/kvm/arm/arch_timer.c
> index c7c3bfd..f27a086 100644
> --- a/virt/kvm/arm/arch_timer.c
> +++ b/virt/kvm/arm/arch_timer.c
> @@ -418,6 +418,31 @@ static int kvm_timer_dying_cpu(unsigned int cpu)
> return 0;
> }
>
> +static bool has_split_eoi_deactivate_support(void)
> +{
> + struct irq_desc *desc;
> + struct irq_data *data;
> + struct irq_chip *chip;
> +
> + /*
> + * Check if split EOI and deactivate is supported on this machine.
> + */
> + desc = irq_to_desc(host_vtimer_irq);
> + if (!desc) {
> + kvm_err("kvm_arch_timer: no host_vtimer_irq descriptor\n");
> + return false;
> + }
> +
> + data = irq_desc_get_irq_data(desc);
> + chip = irq_data_get_irq_chip(data);
> + if (!chip || !chip->irq_set_vcpu_affinity) {
> + kvm_err("kvm_arch_timer: no split EOI/deactivate; abort\n");
> + return false;
> + }
> +
> + return true;
> +}
That feels really involved. How about reporting that we don't have a
usable VGIC altogether from the GIC driver?
> +
> int kvm_timer_hyp_init(void)
> {
> struct arch_timer_kvm_info *info;
> @@ -449,6 +474,11 @@ int kvm_timer_hyp_init(void)
> return err;
> }
>
> + if (!has_split_eoi_deactivate_support()) {
> + disable_percpu_irq(host_vtimer_irq);
> + return -ENODEV;
> + }
> +
> kvm_info("virtual timer IRQ%d\n", host_vtimer_irq);
>
> cpuhp_setup_state(CPUHP_AP_KVM_ARM_TIMER_STARTING,
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/5] drivers: mmc: sunxi: fix A64 calibration routine
From: Maxime Ripard @ 2017-01-05 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-2-git-send-email-andre.przywara@arm.com>
Hi,
On Mon, Jan 02, 2017 at 11:03:42PM +0000, Andre Przywara wrote:
> The calibration facility in the A64 MMC block seems to have been
> misunderstood: the result value is not the value to program into the
> delay bits, but is the number of delay cells that result in a full clock
> cycle delay. So this value has to be scaled by the desired phase, which
> we still have to know and program.
> Change the calibration routine to take a phase parameter and scale the
> calibration value accordingly.
> Also introduce sun50i-a64 delay parameters to store the required phase.
> Looking at the BSP kernel the sample delay for anything below HS200 is
> 0, so we go with that value.
> Once the driver supports HS200 and faster modes, we can enter confirmed
> working values in there.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Exactly how that works hasn't been confirmed, and the only thing that
this patch actually do is... nothing, since the delay is always 0. If
and when we get HS400 to work and we know for a fact how the
calibration works, then we'll be able to use it. Until then, we can
just clear those bits.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/6994a6ab/attachment.sig>
^ permalink raw reply
* [PATCH 3/5] arm64: dts: sun50i: add MMC nodes
From: Maxime Ripard @ 2017-01-05 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483398226-29321-4-git-send-email-andre.przywara@arm.com>
On Mon, Jan 02, 2017 at 11:03:44PM +0000, Andre Przywara wrote:
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 67 +++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index e0dcab8..c680566 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -150,6 +150,32 @@
> pins = "PB8", "PB9";
> function = "uart0";
> };
> +
> + mmc0_pins: mmc0 at 0 {
> + pins = "PF0", "PF1", "PF2", "PF3", "PF4", "PF5";
> + function = "mmc0";
> + drive-strength = <30>;
> + };
> +
> + mmc0_default_cd_pin: mmc0_cd_pin at 0 {
> + pins = "PF6";
> + function = "gpio_in";
> + bias-pull-up;
> + };
> +
> + mmc1_pins: mmc1 at 0 {
> + pins = "PG0", "PG1", "PG2", "PG3", "PG4", "PG5";
> + function = "mmc1";
> + drive-strength = <30>;
> + };
> +
> + mmc2_pins: mmc2 at 0 {
> + pins = "PC1", "PC5", "PC6", "PC8", "PC9",
> + "PC10", "PC11", "PC12", "PC13", "PC14",
> + "PC15", "PC16";
> + function = "mmc2";
> + drive-strength = <30>;
> + };
> };
>
> uart0: serial at 1c28000 {
> @@ -240,6 +266,47 @@
> #size-cells = <0>;
> };
>
> + mmc0: mmc at 1c0f000 {
> + compatible = "allwinner,sun50i-a64-mmc",
> + "allwinner,sun5i-a13-mmc";
That's not correct. There's a bunch of features that are broken
without A64-specific (or at least not present on the A13)
quirks. Those features include for example the SDIO aggregation that
are currently broken for all modes supported so far.
I was in holidays and send those patches tomorrow, but you were a bit
too quick :)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/d1f8b2ae/attachment-0001.sig>
^ permalink raw reply
* [RFC, PATCHv2 29/29] mm, x86: introduce RLIMIT_VADDR
From: Andy Lutomirski @ 2017-01-05 17:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104141959.GC17319@node.shutemov.name>
On Wed, Jan 4, 2017 at 6:19 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
> On Tue, Jan 03, 2017 at 10:27:22AM -0800, Andy Lutomirski wrote:
>> On Tue, Jan 3, 2017 at 8:04 AM, Kirill A. Shutemov <kirill@shutemov.name> wrote:
>> > And what about stack? I'm not sure that everybody would be happy with
>> > stack in the middle of address space.
>>
>> I would, personally. I think that, for very large address spaces, we
>> should allocate a large block of stack and get rid of the "stack grows
>> down forever" legacy idea. Then we would never need to worry about
>> the stack eventually hitting some other allocation. And 2^57 bytes is
>> hilariously large for a default stack.
>
> The stack in the middle of address space can prevent creating other huuuge
> contiguous mapping. Databases may want this.
Fair enough. OTOH, 2^47 is nowhere near the middle if we were to put
it near the top of the legacy address space.
^ permalink raw reply
* [RFC 1/4] mm: remove unused TASK_SIZE_OF()
From: Andy Lutomirski @ 2017-01-05 17:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6DB0258289@AcuExch.aculab.com>
On Thu, Jan 5, 2017 at 1:51 AM, David Laight <David.Laight@aculab.com> wrote:
> From: Dmitry Safonov
>> Sent: 30 December 2016 15:57
>> All users of TASK_SIZE_OF(tsk) have migrated to mm->task_size or
>> TASK_SIZE_MAX since:
>> commit d696ca016d57 ("x86/fsgsbase/64: Use TASK_SIZE_MAX for
>> FSBASE/GSBASE upper limits"),
>> commit a06db751c321 ("pagemap: check permissions and capabilities at
>> open time"),
> ...
>> +#define TASK_SIZE (current->thread.task_size)
>
> I'm not sure I like he hidden 'current' argument to an
> apparent constant.
Me neither. But this patch is merely changing the implementation.
^ permalink raw reply
* [PATCH 1/6] ARM: dts: am335x-phycore-som: Update NAND partition table
From: Brian Norris @ 2017-01-05 17:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105171845.GK4310@atomide.com>
On Thu, Jan 05, 2017 at 09:18:45AM -0800, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170105 07:37]:
> > * Teresa Remmet <t.remmet@phytec.de> [170105 06:57]:
> > > To improve NAND safety we updated the partition layout.
> > > Added barebox backup partition and removed kernel and oftree
> > > partition. They are kept in ubi now.
> >
> > What about the users with earlier partition tables?
> >
> > Please read about "flag day" changes, typically they are not
> > acceptable.
>
> Adding Brian and Adam to Cc. Can you guys come up with some
> solution on this?
I don't have much context for this thread, and no I don't plan to solve
your problems for you. But I can provide tips!
> I'm suggesting we leave the kernel nodes empty and let u-boot
> populate them, so maybe you guys can discuss this on the related
> lists.
That's an option. I've worked with platforms that did something like
this, and that's really one of the only ways you can handle putting
partition information in the device tree. You're really hamstringing
yourself when you put all the partition information in the device tree.
And it's just dumb once that gets codified in the kernel source tree.
The best solution would be to try to migrate away from static device
tree representations of partition info entirely. UBI volumes are best
where possible. If not, then some other kind of on-flash data structures
(along the lines of a GPT) with a corresponding MTD partition parser is
an OK alternative. Unfortunately, there isn't any good standard format
for this on MTD, so it's typically all custom -- and so people use the
easiest approach: device tree. And it's even more difficult with NAND,
which has reliability problems, especially with static data (e.g., read
disturb).
Anyway, the parser solution is helpful only if one can properly fix the
"flag day" first. And it requires a little bit more work to be generally
useful; I posted some work for this over a year ago, but bikeshedding
brought it down.
> The rest of the series looks fine to me so applying it into
> omap-for-v4.11/dt.
Brian
^ permalink raw reply
* [PATCH 2/5] drivers: mmc: sunxi: limit A64 MMC2 to 8K DMA buffer
From: Maxime Ripard @ 2017-01-05 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170104140750.7qs4pvggwjdj5cma@rob-hp-laptop>
Hi Rob,
On Wed, Jan 04, 2017 at 08:07:50AM -0600, Rob Herring wrote:
> On Mon, Jan 02, 2017 at 11:03:43PM +0000, Andre Przywara wrote:
> > From: Maxime Ripard <maxime.ripard@free-electrons.com>
> >
> > Unlike the A64 user manual reports, the third MMC controller on the
> > A64 (and the only one capable of 8-bit HS400 eMMC transfers) has a
> > DMA buffer size limit of 8KB (much like the very old Allwinner SoCs).
> > This does not affect the other two controllers, so introduce a new
> > DT compatible string to let the driver use different settings for that
> > particular device. This will also help to enable the high-speed transfer
> > modes of that controller later.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> > ---
> > Documentation/devicetree/bindings/mmc/sunxi-mmc.txt | 1 +
> > drivers/mmc/host/sunxi-mmc.c | 7 +++++++
> > 2 files changed, 8 insertions(+)
>
> Acked-by: Rob Herring <robh@kernel.org>
Some kind of a digression on this: we have three MMC controllers on
this SoC. Like this patch shows, the third one is clearly different,
and supports both more modes, a wider bus, and specific quirks. We
need a new compatible for this one, everything's perfect.
However, the other two are mostly the same, but seems to need
different tuning parameters to get more performances out of the
controller (but this is unclear yet). How do we usually deal with
that?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/6d02f07c/attachment.sig>
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Brian Norris @ 2017-01-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103114746.141d7d7d@bbrezillon>
On Tue, Jan 03, 2017 at 11:47:46AM +0100, Boris Brezillon wrote:
> On Tue, 3 Jan 2017 12:16:26 +0200
> Vladimir Zapolskiy <vz@mleia.com> wrote:
> > On 01/03/2017 11:12 AM, Boris Brezillon wrote:
> > > Do you need to backport this fix to stable releases? If that's the
> > > case, I'll add the Cc: stable tag when applying.
> >
> > that will be great if you can add
> >
> > Cc: stable at kernel.org # v4.7+
> >
> > Please feel free to add also the tag
> >
> > Fixes: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
>
> Applied to nand/next (this patch will appear in 4.11).
For next time, checkpatch noticed that you got the stable address wrong:
ERROR:STABLE_ADDRESS: The 'stable' address should be 'stable at vger.kernel.org'
#17: Cc: stable at kernel.org # v4.7+
Brian
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Maxime Ripard @ 2017-01-05 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105183734.c56cf3e0be4ad4ac21028851@bidouilliste.com>
On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
>
> Hi,
>
> On Thu, 5 Jan 2017 18:16:01 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > connectors.
> > >
> > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > ---
> > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > index 669a1c338c76..fa8c6f60552b 100644
> > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > @@ -300,12 +300,14 @@
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi1_pins_a>,
> > > <&spi1_cs0_pins_a>;
> > > + status = "okay";
> > > };
> > >
> > > &spi2 {
> > > pinctrl-names = "default";
> > > pinctrl-0 = <&spi2_pins_a>,
> > > <&spi2_cs0_pins_a>;
> > > + status = "okay";
> > > };
> >
> > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > patch?
> >
> > Thanks!
> > Maxime
> >
> > --
> > Maxime Ripard, Free Electrons
> > Embedded Linux and Kernel engineering
> > http://free-electrons.com
>
> It's based on a previous sent patch :
> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
>
> You said you'll squash the two commits.
Hmmm, indeed, I might have made a mistake on this one and ended up
dropping it... :/
I reapplied both and squashed them together, thanks (and sorry again)!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/a970b7d1/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable spi1 and spi2 for Olimex A20 SOM EVB
From: Emmanuel Vadot @ 2017-01-05 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105180151.gooxj3zy53hgojah@lukather>
On Thu, 5 Jan 2017 19:01:51 +0100
Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> On Thu, Jan 05, 2017 at 06:37:34PM +0100, Emmanuel Vadot wrote:
> >
> > Hi,
> >
> > On Thu, 5 Jan 2017 18:16:01 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > Hi,
> > >
> > > On Mon, Dec 26, 2016 at 06:53:49PM +0100, Emmanuel Vadot wrote:
> > > > Enable the spi1 and spi2 node since the pins are exposed on the UEXT
> > > > connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > > > ---
> > > > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 2 ++
> > > > 1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > index 669a1c338c76..fa8c6f60552b 100644
> > > > --- a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > +++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
> > > > @@ -300,12 +300,14 @@
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi1_pins_a>,
> > > > <&spi1_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > > >
> > > > &spi2 {
> > > > pinctrl-names = "default";
> > > > pinctrl-0 = <&spi2_pins_a>,
> > > > <&spi2_cs0_pins_a>;
> > > > + status = "okay";
> > > > };
> > >
> > > Those nodes don't exist unfortunately. Maybe you forgot to send one
> > > patch?
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > It's based on a previous sent patch :
> > http://lists.infradead.org/pipermail/linux-arm-kernel/2016-November/469288.html
> >
> > You said you'll squash the two commits.
>
> Hmmm, indeed, I might have made a mistake on this one and ended up
> dropping it... :/
>
> I reapplied both and squashed them together, thanks (and sorry again)!
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
No problem, thank you!
--
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
^ permalink raw reply
* [PATCH v3 7/9] arm64: cpufeature: Track user visible fields
From: Catalin Marinas @ 2017-01-05 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-8-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:05PM +0000, Suzuki K. Poulose wrote:
> Track the user visible fields of a CPU feature register. This will be
> used for exposing the value to the userspace. All the user visible
> fields of a feature register will be passed on as it is, while the
> others would be filled with their respective safe value.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
> @@ -81,75 +82,75 @@ cpufeature_pan_not_uao(const struct arm64_cpu_capabilities *entry, int __unused)
>
>
> static const struct arm64_ftr_bits ftr_id_aa64isar0[] = {
> - ARM64_FTR_BITS(FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> - ARM64_FTR_BITS(FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_EXACT, ID_AA64ISAR0_RDM_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_ATOMICS_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_CRC32_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA2_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_SHA1_SHIFT, 4, 0),
> + ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64ISAR0_AES_SHIFT, 4, 0),
BTW, as a separate patch I think we need to expose the RDM field in this
register as well, together with a corresponding HWCAP bit.
--
Catalin
^ permalink raw reply
* [RFC PATCH 1/7] arm64: Use physical counter for in-kernel reads
From: Marc Zyngier @ 2017-01-05 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161210204712.21830-2-christoffer.dall@linaro.org>
[adding the arm64 maintainers, plus Mark as arch timer maintainer]
On 10/12/16 20:47, Christoffer Dall wrote:
> Using the physical counter allows KVM to retain the offset between the
> virtual and physical counter as long as it is actively running a VCPU.
>
> As soon as a VCPU is released, another thread is scheduled or we start
> running userspace applications, we reset the offset to 0, so that VDSO
> operations can still read the virtual counter and get the same view of
> time as the kernel.
>
> This opens up potential improvements for KVM performance.
>
> VHE kernels or kernels using the virtual timer are unaffected by this.
>
> Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
> ---
> arch/arm64/include/asm/arch_timer.h | 6 ++++--
> drivers/clocksource/arm_arch_timer.c | 2 +-
> 2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index eaa5bbe..cec2549 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -139,11 +139,13 @@ static inline void arch_timer_set_cntkctl(u32 cntkctl)
>
> static inline u64 arch_counter_get_cntpct(void)
> {
> + u64 cval;
> /*
> * AArch64 kernel and user space mandate the use of CNTVCT.
> */
> - BUG();
> - return 0;
> + isb();
> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
> + return cval;
> }
>
> static inline u64 arch_counter_get_cntvct(void)
> diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
> index 73c487d..a5b0789 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -597,7 +597,7 @@ static void __init arch_counter_register(unsigned type)
>
> /* Register the CP15 based counter if we have one */
> if (type & ARCH_CP15_TIMER) {
> - if (IS_ENABLED(CONFIG_ARM64) || arch_timer_uses_ppi == VIRT_PPI)
> + if (arch_timer_uses_ppi == VIRT_PPI || is_kernel_in_hyp_mode())
Why do we have this is_kernel_in_hyp_mode clause? I can't think of any
reason for a VHE kernel to use the virtual counter at all...
> arch_timer_read_counter = arch_counter_get_cntvct;
> else
> arch_timer_read_counter = arch_counter_get_cntpct;
>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ARM: dts: sun7i: Add wifi dt node on Banana Pro
From: Maxime Ripard @ 2017-01-05 18:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105173753.14024-1-joerg.krause@embedded.rocks>
Hi J?rg,
On Thu, Jan 05, 2017 at 06:37:53PM +0100, J?rg Krause wrote:
> The Banana Pro has an AMPAK AP6181 WiFi+Bluetooth module. The WiFi part
> is a BCM43362 IC connected to MMC3 of the A20 SoC via SDIO. The IC also
> takes a power enable signal via GPIO.
>
> This commit adds a device-tree node to power it up, so the mmc subsys
> can scan it, and enables the mmc controller which is connected to it.
>
> As the wifi enable pin of the AP6181 module is not really a regulator,
> switch the mmc3 node to the mmc-pwrseq framework for controlling it.
> This more accurately reflectes how the hardware actually works.
>
> Signed-off-by: J?rg Krause <joerg.krause@embedded.rocks>
> ---
> Changes v2 (suggested by Maxime Ripard):
> - rename pwrseq node to clarify the function rather what it's
> connected to
> - use dash instead of underscore for the pwrseq node name
> - remove setting pull-ups for mmc3 (default since commit 37bc56128d92)
>
> ---
> arch/arm/boot/dts/sun7i-a20-bananapro.dts | 30 ++++++++++++++++++------------
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> index 19d63d4049de..77f8fb76c157 100644
> --- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
> @@ -76,6 +76,13 @@
> };
> };
>
> + wifi_pwrseq: wifi-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + pinctrl-names = "default";
> + pinctrl-0 = <&vmmc3_pin_bananapro>;
> + reset-gpios = <&pio 7 22 GPIO_ACTIVE_LOW>;
> + };
> +
> reg_gmac_3v3: gmac-3v3 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> @@ -87,17 +94,6 @@
> enable-active-high;
> gpio = <&pio 7 23 GPIO_ACTIVE_HIGH>;
> };
> -
> - reg_vmmc3: vmmc3 {
> - compatible = "regulator-fixed";
> - pinctrl-names = "default";
> - pinctrl-0 = <&vmmc3_pin_bananapro>;
> - regulator-name = "vmmc3";
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - enable-active-high;
> - gpio = <&pio 7 22 GPIO_ACTIVE_HIGH>;
> - };
> };
>
> &ahci {
> @@ -166,10 +162,20 @@
> &mmc3 {
> pinctrl-names = "default";
> pinctrl-0 = <&mmc3_pins_a>;
> - vmmc-supply = <®_vmmc3>;
> + vmmc-supply = <®_vcc3v3>;
> + mmc-pwrseq = <&wifi_pwrseq>;
> bus-width = <4>;
> non-removable;
> + wakeup-source;
Sorry for not spotting that earlier, but this is suspicious. The PIO
is not able to be wake up the CPU, since it's connected to the GIC
that is shut down during CPU suspend. Our only wake up source is the
NMI controller. So either it is not able to wake up the system, or the
interrupt line in not the right one.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170105/67bd8828/attachment.sig>
^ permalink raw reply
* [PATCH] mtd: nand: lpc32xx: fix invalid error handling of a requested irq
From: Vladimir Zapolskiy @ 2017-01-05 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105175851.GC50438@google.com>
On 01/05/2017 07:58 PM, Brian Norris wrote:
> On Tue, Jan 03, 2017 at 11:47:46AM +0100, Boris Brezillon wrote:
>> On Tue, 3 Jan 2017 12:16:26 +0200
>> Vladimir Zapolskiy <vz@mleia.com> wrote:
>>> On 01/03/2017 11:12 AM, Boris Brezillon wrote:
>>>> Do you need to backport this fix to stable releases? If that's the
>>>> case, I'll add the Cc: stable tag when applying.
>>>
>>> that will be great if you can add
>>>
>>> Cc: stable at kernel.org # v4.7+
>>>
>>> Please feel free to add also the tag
>>>
>>> Fixes: 8cb17b5ed017 ("irqchip: Add LPC32xx interrupt controller driver")
>>
>> Applied to nand/next (this patch will appear in 4.11).
>
> For next time, checkpatch noticed that you got the stable address wrong:
>
> ERROR:STABLE_ADDRESS: The 'stable' address should be 'stable at vger.kernel.org'
> #17: Cc: stable at kernel.org # v4.7+
>
> Brian
>
sorry, I've git-logged to commit 52bce91165 and pasted the address from
its commit message.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH] cpufreq: Remove CONFIG_CPU_FREQ_STAT_DETAILS config option
From: Krzysztof Kozlowski @ 2017-01-05 18:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d4299228a500a889c2b4b9e305674f3d1ea9ae06.1483604760.git.viresh.kumar@linaro.org>
On Thu, Jan 05, 2017 at 01:57:41PM +0530, Viresh Kumar wrote:
> This doesn't have any benefit apart from saving a small amount of memory
> when it is disabled. The ifdef hackery in the code makes it dirty
> unnecessarily.
>
> Clean it up by removing the Kconfig option completely. Few defconfigs
> are also updated and CONFIG_CPU_FREQ_STAT_DETAILS is replaced with
> CONFIG_CPU_FREQ_STAT now in them, as users wanted stats to be enabled.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
> ---
> arch/arm/configs/exynos_defconfig | 2 +-
> arch/arm/configs/multi_v5_defconfig | 2 +-
> arch/arm/configs/multi_v7_defconfig | 2 +-
> arch/arm/configs/mvebu_v5_defconfig | 2 +-
> arch/arm/configs/pxa_defconfig | 2 +-
> arch/arm/configs/shmobile_defconfig | 2 +-
> arch/mips/configs/lemote2f_defconfig | 1 -
> arch/powerpc/configs/ppc6xx_defconfig | 1 -
> arch/sh/configs/sh7785lcr_32bit_defconfig | 2 +-
> drivers/cpufreq/Kconfig | 8 --------
> drivers/cpufreq/cpufreq_stats.c | 14 --------------
> 11 files changed, 7 insertions(+), 31 deletions(-)
>
> diff --git a/arch/arm/configs/exynos_defconfig b/arch/arm/configs/exynos_defconfig
> index 79c415c33f69..809f0bf3042a 100644
> --- a/arch/arm/configs/exynos_defconfig
> +++ b/arch/arm/configs/exynos_defconfig
> @@ -24,7 +24,7 @@ CONFIG_ARM_APPENDED_DTB=y
> CONFIG_ARM_ATAG_DTB_COMPAT=y
> CONFIG_CMDLINE="root=/dev/ram0 rw ramdisk=8192 initrd=0x41000000,8M console=ttySAC1,115200 init=/linuxrc mem=256M"
> CONFIG_CPU_FREQ=y
> -CONFIG_CPU_FREQ_STAT_DETAILS=y
> +CONFIG_CPU_FREQ_STAT=y
> CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
> CONFIG_CPU_FREQ_GOV_POWERSAVE=m
> CONFIG_CPU_FREQ_GOV_USERSPACE=m
For Exynos:
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2 3/4] arm64: dts: exynos: make tm2 and tm2e independent from each other
From: Krzysztof Kozlowski @ 2017-01-05 18:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105092315.swensammin4wbgx5@gangnam.samsung>
On Thu, Jan 05, 2017 at 06:23:15PM +0900, Andi Shyti wrote:
> Hi Chanwoo,
>
> > I add the some comment as following:
> > - ldo23/25/31/38 have the different value between tm2 and tm2e.
>
> Thanks for pointing this out. I planned to do this already in a
> following patch as for now I think it's out from the scope of this
> particular patch.
>
> > - The patch[1] was alread posted. I think you better to rebase this patch on patch[1].
> > [1] https://patchwork.kernel.org/patch/9491769/
> > - ("ARM64: dts: TM2: comply to the samsung pinctrl naming convention")
>
> Yes, I also thought about this, but I didn't know whether it was
> already picked by anyone. I didn't want to stop Jaechul that's
> why I was planning to rebase the other rather than this.
> But you are right, because some bits of the other patches I know
> that have been merged. Thank you!
>
> Krzysztof, do you mind if I send patch 3 as a reply to this
> e-mail? The changes should not affect patch 4, anyway.
By patch 3 you mean this patch? Yes, you can send another version as a
reply-to but please version it (2.1? etc).
Anyway I need a proper rename detection. I pointed proper command last
time. Is it working?
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 8/9] arm64: cpufeature: Expose CPUID registers by emulation
From: Catalin Marinas @ 2017-01-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483552147-9605-9-git-send-email-suzuki.poulose@arm.com>
On Wed, Jan 04, 2017 at 05:49:06PM +0000, Suzuki K. Poulose wrote:
> This patch adds the hook for emulating MRS instruction to
> export the 'user visible' value of supported system registers.
> We emulate only the following id space for system registers:
>
> Op0=3, Op1=0, CRn=0, CRm=[0, 4-7]
>
> The rest will fall back to SIGILL. This capability is also
> advertised via a new HWCAP_CPUID.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH v2 4/4] arm64: dts: exynos: Add tm2 touchkey node
From: Krzysztof Kozlowski @ 2017-01-05 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483604833-29746-5-git-send-email-jcsing.lee@samsung.com>
On Thu, Jan 05, 2017 at 05:27:13PM +0900, Jaechul Lee wrote:
> Add DT node support for TM2 touchkey device.
>
> Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
> Signed-off-by: Jaechul Lee <jcsing.lee@samsung.com>
> Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Although I said the patch looks correct, it was not an explicit Review
(and we have a quite serious "Reviewer's statement of oversight") so my
tag should not be added.
No harm was done, but I prefer clearly and explicitly given tags.
Best regards,
Krzysztof
> ---
> arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> index aa8584a..dad6fb8 100644
> --- a/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> +++ b/arch/arm64/boot/dts/exynos/exynos5433-tm2.dts
> @@ -17,3 +17,16 @@
> model = "Samsung TM2 board";
> compatible = "samsung,tm2", "samsung,exynos5433";
> };
> +
> +&hsi2c_9 {
> + status = "okay";
> +
> + touchkey at 20 {
> + compatible = "samsung,tm2-touchkey";
> + reg = <0x20>;
> + interrupt-parent = <&gpa3>;
> + interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
> + vcc-supply = <&ldo32_reg>;
> + vdd-supply = <&ldo33_reg>;
> + };
> +};
> --
> 2.7.4
>
^ permalink raw reply
* [PATCH v3 0/4] TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x UART
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
This series adds a new UART port type for TI DA8xx/OMAPL13x/AM17xx/AM18xx/66AK2x
UART. These SoCs have a non-standard register for UART power management that
needs special handling in the UART driver.
Greg, the first two patches will need to go through your tree. Sekhar and
Santosh will pick up the 3 and 4 patches respectively.
v3 changes:
* Shortened list of SoCs to "DA8xx/66AK2x"
v2 changes:
* Added references to C66x SoC in various places, which I assume is an OK
shorthand for TI Keystone processors.
* New patch for Keystone device tree. This is untested as I don't have any
Keystone boards.
David Lechner (4):
doc: DT: Add ti,da830-uart to serial/8250 bindings
serial: 8250: Add new port type for TI DA8xx/66AK2x
ARM: da850: Add ti,da830-uart compatible for serial ports
ARM: dts: keystone: Add "ti,da830-uart" compatible string
Documentation/devicetree/bindings/serial/8250.txt | 1 +
arch/arm/boot/dts/da850.dtsi | 9 ++++++---
arch/arm/boot/dts/keystone-k2g.dtsi | 2 +-
arch/arm/boot/dts/keystone-k2l.dtsi | 4 ++--
arch/arm/boot/dts/keystone.dtsi | 4 ++--
drivers/tty/serial/8250/8250_of.c | 1 +
drivers/tty/serial/8250/8250_port.c | 22 ++++++++++++++++++++++
include/uapi/linux/serial_core.h | 3 ++-
include/uapi/linux/serial_reg.h | 8 ++++++++
9 files changed, 45 insertions(+), 9 deletions(-)
--
2.7.4
^ permalink raw reply
* [PATCH v3 1/4] doc: DT: Add ti,da830-uart to serial/8250 bindings
From: David Lechner @ 2017-01-05 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483642460-6891-1-git-send-email-david@lechnology.com>
This adds the ti,da830-uart compatible string to serial 8250 UART bindings.
Signed-off-by: David Lechner <david@lechnology.com>
Acked-by: Rob Herring <robh@kernel.org>
---
v3 changes:
* None
v2 changes:
* picked up Acked-by:
Documentation/devicetree/bindings/serial/8250.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/serial/8250.txt b/Documentation/devicetree/bindings/serial/8250.txt
index f86bb06..10276a4 100644
--- a/Documentation/devicetree/bindings/serial/8250.txt
+++ b/Documentation/devicetree/bindings/serial/8250.txt
@@ -19,6 +19,7 @@ Required properties:
- "altr,16550-FIFO128"
- "fsl,16550-FIFO64"
- "fsl,ns16550"
+ - "ti,da830-uart"
- "serial" if the port type is unknown.
- reg : offset and length of the register set for the device.
- interrupts : should contain uart interrupt.
--
2.7.4
^ 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