* [PATCH v4 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: honghui.zhang at mediatek.com @ 2017-12-22 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513921178-16148-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
There maybe a same IRQ reentry scenario after IRQ received in current
IRQ handle flow:
EP device PCIe host driver EP driver
1. issue an IRQ
2. received IRQ
3. clear IRQ status
4. dispatch IRQ
5. clear IRQ source
The IRQ status was not successfully cleared at step 2 since the IRQ
source was not cleared yet. So the PCIe host driver may receive the
same IRQ after step 5. Then there's an IRQ reentry occurred.
Even worse, if the reentry IRQ was not an IRQ that EP driver expected,
it may not handle the IRQ. Then we may run into the infinite loop from
step 2 to step 4.
Clear the IRQ status after IRQ have been dispatched to avoid the IRQ
reentry.
This patch also fix another INTx IRQ issue by initialize the iterate
before the loop. If an INTx IRQ re-occurred while we are dispatching
the INTx IRQ, then iterate may start from PCI_NUM_INTX + INTX_SHIFT
instead of INTX_SHIFT for the second time entering the
for_each_set_bit_from() loop.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
Acked-by: Ryder Lee <ryder.lee@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 11 ++++++-----
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index db93efd..fc29a9a 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -601,15 +601,16 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
struct mtk_pcie_port *port = (struct mtk_pcie_port *)data;
unsigned long status;
u32 virq;
- u32 bit = INTX_SHIFT;
+ u32 bit;
while ((status = readl(port->base + PCIE_INT_STATUS)) & INTX_MASK) {
+ bit = INTX_SHIFT;
for_each_set_bit_from(bit, &status, PCI_NUM_INTX + INTX_SHIFT) {
- /* Clear the INTx */
- writel(1 << bit, port->base + PCIE_INT_STATUS);
virq = irq_find_mapping(port->irq_domain,
bit - INTX_SHIFT);
generic_handle_irq(virq);
+ /* Clear the INTx */
+ writel(1 << bit, port->base + PCIE_INT_STATUS);
}
}
@@ -619,10 +620,10 @@ static irqreturn_t mtk_pcie_intr_handler(int irq, void *data)
while ((imsi_status = readl(port->base + PCIE_IMSI_STATUS))) {
for_each_set_bit(bit, &imsi_status, MTK_MSI_IRQS_NUM) {
- /* Clear the MSI */
- writel(1 << bit, port->base + PCIE_IMSI_STATUS);
virq = irq_find_mapping(port->msi_domain, bit);
generic_handle_irq(virq);
+ /* Clear the MSI */
+ writel(1 << bit, port->base + PCIE_IMSI_STATUS);
}
}
/* Clear MSI interrupt status */
--
2.6.4
^ permalink raw reply related
* [PATCH v4 2/2] PCI: mediatek: Set up class type and vendor ID for MT7622
From: honghui.zhang at mediatek.com @ 2017-12-22 5:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513921178-16148-1-git-send-email-honghui.zhang@mediatek.com>
From: Honghui Zhang <honghui.zhang@mediatek.com>
The hardware default value of IDs and class type is not correct,
fix that by setup the correct values before start up.
Signed-off-by: Honghui Zhang <honghui.zhang@mediatek.com>
---
drivers/pci/host/pcie-mediatek.c | 12 ++++++++++++
include/linux/pci_ids.h | 3 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/pci/host/pcie-mediatek.c b/drivers/pci/host/pcie-mediatek.c
index fc29a9a..0ef33e4 100644
--- a/drivers/pci/host/pcie-mediatek.c
+++ b/drivers/pci/host/pcie-mediatek.c
@@ -74,6 +74,10 @@
/* PCIe V2 per-port registers */
#define PCIE_MSI_VECTOR 0x0c0
+
+#define PCIE_CONF_ID 0x100
+#define PCIE_CONF_CLASS 0x104
+
#define PCIE_INT_MASK 0x420
#define INTX_MASK GENMASK(19, 16)
#define INTX_SHIFT 16
@@ -393,6 +397,14 @@ static int mtk_pcie_startup_port_v2(struct mtk_pcie_port *port)
val |= PCIE_CSR_LTSSM_EN(port->slot) |
PCIE_CSR_ASPM_L1_EN(port->slot);
writel(val, pcie->base + PCIE_SYS_CFG_V2);
+
+ /* Set up vendor ID and device ID for MT7622*/
+ val = PCI_VENDOR_ID_MEDIATEK | (PCI_DEVICE_ID_MT7622 << 16);
+ writel(val, port->base + PCIE_CONF_ID);
+
+ /* Set up class code for MT7622 */
+ val = PCI_CLASS_BRIDGE_PCI << 16;
+ writel(val, port->base + PCIE_CONF_CLASS);
}
/* Assert all reset signals */
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ab20dc5..000c5df 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2113,6 +2113,9 @@
#define PCI_VENDOR_ID_MYRICOM 0x14c1
+#define PCI_VENDOR_ID_MEDIATEK 0x14c3
+#define PCI_DEVICE_ID_MT7622 0x5396
+
#define PCI_VENDOR_ID_TITAN 0x14D2
#define PCI_DEVICE_ID_TITAN_010L 0x8001
#define PCI_DEVICE_ID_TITAN_100L 0x8010
--
2.6.4
^ permalink raw reply related
* [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2
From: sean.wang at mediatek.com @ 2017-12-22 6:06 UTC (permalink / raw)
To: linux-arm-kernel
From: Sean Wang <sean.wang@mediatek.com>
On bpi-r2 board, totally there're four uarts which we usually called
uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has
dedicated pin slot which is used to conolse log. uart[0-1] appear at the
40-pins connector and uart3 has no pinout, but just has test points (TP47
for TX and TP48 for RX, respectively) nearby uart2. Also, some missing
pinctrl is being complemented for those devices.
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
---
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
index 7bf5aa2..64bf5db 100644
--- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
+++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
@@ -409,6 +409,20 @@
<MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
};
};
+
+ uart2_pins_a: uart at 2 {
+ pins_dat {
+ pinmux = <MT7623_PIN_14_GPIO14_FUNC_URXD2>,
+ <MT7623_PIN_15_GPIO15_FUNC_UTXD2>;
+ };
+ };
+
+ uart3_pins_a: uart at 3 {
+ pins_dat {
+ pinmux = <MT7623_PIN_242_URTS2_FUNC_URTS2>,
+ <MT7623_PIN_243_UCTS2_FUNC_UTXD3>;
+ };
+ };
};
&pwm {
@@ -454,16 +468,24 @@
&uart0 {
pinctrl-names = "default";
pinctrl-0 = <&uart0_pins_a>;
- status = "disabled";
+ status = "okay";
};
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&uart1_pins_a>;
- status = "disabled";
+ status = "okay";
};
&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart2_pins_a>;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart3_pins_a>;
status = "okay";
};
--
2.7.4
^ permalink raw reply related
* [PATCH v2] IPI performance benchmark
From: Yury Norov @ 2017-12-22 6:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANRm+Cx6Lm8r2Oej+-EX=Dz76bvu81rVKD-RU0=LRSNs3dw7mw@mail.gmail.com>
On Wed, Dec 20, 2017 at 02:44:25PM +0800, Wanpeng Li wrote:
> Hi Yury,
> 2017-12-19 16:50 GMT+08:00 Yury Norov <ynorov@caviumnetworks.com>:
> > This benchmark sends many IPIs in different modes and measures
> > time for IPI delivery (first column), and total time, ie including
> > time to acknowledge the receive by sender (second column).
> >
> > The scenarios are:
> > Dry-run: do everything except actually sending IPI. Useful
> > to estimate system overhead.
> > Self-IPI: Send IPI to self CPU.
> > Normal IPI: Send IPI to some other CPU.
> > Broadcast IPI: Send broadcast IPI to all online CPUs.
> > Broadcast lock: Send broadcast IPI to all online CPUs and force them
> > acquire/release spinlock.
> >
> > The raw output looks like this:
> > [ 155.363374] Dry-run: 0, 2999696 ns
> > [ 155.429162] Self-IPI: 30385328, 65589392 ns
> > [ 156.060821] Normal IPI: 566914128, 631453008 ns
> > [ 158.384427] Broadcast IPI: 0, 2323368720 ns
> > [ 160.831850] Broadcast lock: 0, 2447000544 ns
> >
> > For virtualized guests, sending and reveiving IPIs causes guest exit.
> > I used this test to measure performance impact on KVM subsystem of
> > Christoffer Dall's series "Optimize KVM/ARM for VHE systems" [1].
> >
> > Test machine is ThunderX2, 112 online CPUs. Below the results normalized
> > to host dry-run time, broadcast lock results omitted. Smaller - better.
>
> Could you test on a x86 box? I see a lot of calltraces on my haswell
> client host, there is no calltrace in the guest, however, I can still
> observe "Invalid parameters" warning when insmod this module. In
> addition, the x86 box fails to boot when ipi_benchmark is buildin.
EINVAL is returned intentionally to let user run test again without
annoying rmmod.
^ permalink raw reply
* [clk:clk-next 130/133] drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
From: Sean Wang @ 2017-12-22 6:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201712221239.y5YaQIlV%fengguang.wu@intel.com>
thanks, i will try to have a fixup
Sean
On Fri, 2017-12-22 at 12:42 +0800, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git clk-next
> head: 813bf3417374b0f382d4bfbd712c54794d943c57
> commit: 74cb0d6dde85fef197aca3b2976487e99934309d [130/133] clk: mediatek: fixup test-building of MediaTek clock drivers
> config: sparc64-allmodconfig (attached as .config)
> compiler: sparc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
> reproduce:
> wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> git checkout 74cb0d6dde85fef197aca3b2976487e99934309d
> # save the attached .config to linux build tree
> make.cross ARCH=sparc64
>
> All warnings (new ones prefixed by >>):
>
> In file included from drivers/clk/mediatek/reset.c:22:0:
> >> drivers/clk/mediatek/clk-mtk.h:44:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> int num, struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:63:19: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> int num, struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:145:10: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:164:11: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
> drivers/clk/mediatek/clk-mtk.h:190:12: warning: 'struct clk_onecell_data' declared inside parameter list will not be visible outside of this definition or declaration
> struct clk_onecell_data *clk_data);
> ^~~~~~~~~~~~~~~~
>
> vim +44 drivers/clk/mediatek/clk-mtk.h
>
> 4fa04380 James Liao 2015-07-10 35
> 4fa04380 James Liao 2015-07-10 36 #define FIXED_CLK(_id, _name, _parent, _rate) { \
> 4fa04380 James Liao 2015-07-10 37 .id = _id, \
> 4fa04380 James Liao 2015-07-10 38 .name = _name, \
> 4fa04380 James Liao 2015-07-10 39 .parent = _parent, \
> 4fa04380 James Liao 2015-07-10 40 .rate = _rate, \
> 4fa04380 James Liao 2015-07-10 41 }
> 4fa04380 James Liao 2015-07-10 42
> 4fa04380 James Liao 2015-07-10 43 void mtk_clk_register_fixed_clks(const struct mtk_fixed_clk *clks,
> 4fa04380 James Liao 2015-07-10 @44 int num, struct clk_onecell_data *clk_data);
> 4fa04380 James Liao 2015-07-10 45
>
> :::::: The code at line 44 was first introduced by commit
> :::::: 4fa043806a2cdbf86503068276ab9bba91a726f6 clk: mediatek: Add fixed clocks support for Mediatek SoC.
>
> :::::: TO: James Liao <jamesjj.liao@mediatek.com>
> :::::: CC: James Liao <jamesjj.liao@mediatek.com>
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* [PATCH] arm: dts: mt7623: enable all four available UARTs on bananapi-r2
From: Sean Wang @ 2017-12-22 6:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b4e84a68da76c1ca538150a730777ff530c1db5a.1513922513.git.sean.wang@mediatek.com>
On Fri, 2017-12-22 at 14:06 +0800, sean.wang at mediatek.com wrote:
> From: Sean Wang <sean.wang@mediatek.com>
>
> On bpi-r2 board, totally there're four uarts which we usually called
> uart[0-3] helpful to extend slow I/O devices. Among those ones, uart2 has
> dedicated pin slot which is used to conolse log. uart[0-1] appear at the
Hi, Matthias
Could you help to fix the misspelling "conolse" with "console" when you
merge the patch ?
Sean
> 40-pins connector and uart3 has no pinout, but just has test points (TP47
> for TX and TP48 for RX, respectively) nearby uart2. Also, some missing
> pinctrl is being complemented for those devices.
>
> Signed-off-by: Sean Wang <sean.wang@mediatek.com>
> ---
> arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts | 26 ++++++++++++++++++++++++--
> 1 file changed, 24 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> index 7bf5aa2..64bf5db 100644
> --- a/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> +++ b/arch/arm/boot/dts/mt7623n-bananapi-bpi-r2.dts
> @@ -409,6 +409,20 @@
> <MT7623_PIN_82_UTXD1_FUNC_UTXD1>;
> };
> };
> +
> + uart2_pins_a: uart at 2 {
> + pins_dat {
> + pinmux = <MT7623_PIN_14_GPIO14_FUNC_URXD2>,
> + <MT7623_PIN_15_GPIO15_FUNC_UTXD2>;
> + };
> + };
> +
> + uart3_pins_a: uart at 3 {
> + pins_dat {
> + pinmux = <MT7623_PIN_242_URTS2_FUNC_URTS2>,
> + <MT7623_PIN_243_UCTS2_FUNC_UTXD3>;
> + };
> + };
> };
>
> &pwm {
> @@ -454,16 +468,24 @@
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pins_a>;
> - status = "disabled";
> + status = "okay";
> };
>
> &uart1 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart1_pins_a>;
> - status = "disabled";
> + status = "okay";
> };
>
> &uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins_a>;
> + status = "okay";
> +};
> +
> +&uart3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart3_pins_a>;
> status = "okay";
> };
>
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Herbert Xu @ 2017-12-22 6:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171129084121.9385-2-clabbe.montjoie@gmail.com>
On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> The crypto engine could actually only enqueue hash and ablkcipher request.
> This patch permit it to enqueue any type of crypto_async_request.
>
> Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
This is going the wrong way. We do not want to expose any of the
base types such as crypto_alg, crypto_async_request to end-users
and that includes drivers. Only core API code should touch these
base types.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH v2] i2c/ARM: davinci: Deep refactoring of I2C recovery
From: Arnd Bergmann @ 2017-12-22 7:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYhtrVKk36cza_RUysjp_ZYvT5D0nCGdG3K9=SGsdJNLA@mail.gmail.com>
On Thu, Dec 21, 2017 at 11:30 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 4:36 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> On Wed, Dec 20, 2017 at 1:17 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> Alter the DaVinci GPIO recovery fetch to use descriptors
>>> all the way down into the board files.
>>>
>>> Cc: arm at kernel.org
>>> Cc: Kevin Hilman <khilman@kernel.org>
>>> Cc: Keerthy <j-keerthy@ti.com>
>>> Cc: Sekhar Nori <nsekhar@ti.com>
>>> Acked-by: Sekhar Nori <nsekhar@ti.com>
>>> Tested-by: Sekhar Nori <nsekhar@ti.com>
>>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>>> ---
>>> ChangeLog v1->v2:
>>> - Change gpiochip name from gpio_davinci.0 to gpio_davinci, simply.
>>
>> This seems to clash with "i2c: davinci: Add PM Runtime Support", please
>> rebase on top of v4.15-rc and resend.
>
> Strange, where do you see this problem?
>
> I just applied the patch on top of Wolfram's for-next
> branch and it worked like a charm. It has the PM Runtime patch
> underneath and all.
I looked at v4.15-rc4, but haven't analyzed further.
Arnd
^ permalink raw reply
* [PATCH] ARM: realview: remove eb-mp clcd IRQ
From: Arnd Bergmann @ 2017-12-22 7:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbCWZB1ZkrdGe0s0GfNVWEYY+NThy4ce-+SBtU-s=WNbQ@mail.gmail.com>
On Thu, Dec 21, 2017 at 11:08 PM, Linus Walleij
<linus.walleij@linaro.org> wrote:
> On Thu, Dec 21, 2017 at 10:31 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
>> We get a dtc warning about the CLCD interrupt being invalid:
>>
>> arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning (interrupts_property): interrupts size is (8), expected multiple of 12 in /fpga/charlcd at 10008000
>>
>> According to the datasheet I found and the old board file, this
>> line is not connected, so I'm removing the respective properties here.
>>
>> Link: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0411d/index.html
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> There is some confusion here. There is CLCD "Color LCD"
> which is just a code name for PrimeCell PL111 and there is the actual
> character LCD which is a hardware thin to talk to a character LCD with
> some characters on.
>
>> diff --git a/arch/arm/boot/dts/arm-realview-eb-mp.dtsi b/arch/arm/boot/dts/arm-realview-eb-mp.dtsi
>
> So this DTS is for the ARM 11 MP core tile which is described in
> DUI0318F. It doesn't even list an IRQ for the character LCD.
>
>> &charlcd {
>> - interrupt-parent = <&intc>;
>> - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
>
> This was probably me thinking to go back and fill in the right
> IRQ and forgetting to actually do it. Sorry :(
>
>> + /* CLCD is not connected here */
>
> Call it character LCD instead to avoid confusion please.
>
>> + /delete-property/interrupt-parent;
>> + /delete-property/interrupts;
>
> I don't understand this delete-property business (first time
> I see it, but the top level
> DTSI (arm-realview-eb.dtsi) does not define any interrupt
> so can't you just delete this whole &charlcd?
>
> I do think the reference design has a character LCD, and I
> do think it has an interrupt, it's just undocumented so
> someone with this board would have to test it manually
> to figure out which line it is. Whoever uses this design
> will get to it if ever.
Sounds good, can you prepare a patch for this?
We are getting very close to zero warnings now with the
latest arm-soc/for-next branch:
arch/arm/boot/dts/arm-realview-eb-11mp.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-ctrevb.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-a9mp.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-11mp-bbrevd-ctrevb.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/arm-realview-eb-a9mp-bbrevd.dtb: Warning
(interrupts_property): interrupts size is (8), expected multiple of 12
in /fpga/charlcd at 10008000
arch/arm/boot/dts/s5pv210-smdkv210.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-smdkc110.dtb: Warning (interrupts_property):
arch/arm/boot/dts/s5pv210-goni.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-aquila.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/s5pv210-torbreck.dtb: Warning (interrupts_property):
Missing interrupt-parent for /soc/ohci at ec300000
arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property):
Property 'cs-gpios', cell 6 is not a phandle reference in
/ahb/apb/spi at e0100000
arch/arm/boot/dts/spear1310-evb.dtb: Warning (gpios_property): Missing
property '#gpio-cells' in node /interrupt-controller at ec801000 or bad
phandle (referred from /ahb/apb/spi at e0100000:cs-gpios[6])
arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Property
'dmas', cell 4 is not a phandle reference in /ahb/apb/serial at b4100000
arch/arm/boot/dts/spear1340-evb.dtb: Warning (dmas_property): Missing
property '#dma-cells' in node /interrupt-controller at ec801000 or bad
phandle (referred from /ahb/apb/serial at b4100000:dmas[4])
arch/arm/boot/dts/stih407-b2120.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/stih410-b2120.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/stih410-b2260.dtb: Warning (gpios_property):
hdmi,hpd-gpio property size (8) too small for cell size 2 in
/soc/sti-display-subsystem/sti-hdmi at 8d04000
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property):
power-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-ea3250.dtb: Warning (gpios_property):
reset-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property):
power-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/lpc3250-phy3250.dtb: Warning (gpios_property):
reset-gpio property size (12) too small for cell size 3 in
/ahb/apb/i2c at 400A0000/uda1380 at 18
arch/arm/boot/dts/ste-nomadik-s8815.dtb: Warning
(interrupts_property): Missing interrupt-parent for
/amba/clcd at 10120000
arch/arm/boot/dts/ste-nomadik-nhk15.dtb: Warning
(interrupts_property): Missing interrupt-parent for
/amba/clcd at 10120000
arch/arm/boot/dts/spear600-evb.dtb: Warning (interrupts_property):
Missing interrupt-parent for /ahb/apb/rtc at fc900000
Can you also look at the nomadik warnings and possibly some of the others
if you have time? Unfortunately I'm heading out for my Christmas vacation
and can't do any others of these any more.
Arnd
^ permalink raw reply
* [PATCH v2 4/6] ARM: dts: imx6: Add support for phxBOARD-Mira i.MX 6 DualLight/Solo RDK
From: Stefan Riedmüller @ 2017-12-22 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171220151008.4aa4b5a5@karo-electronics.de>
Hi,
On 20.12.2017 15:10, Lothar Wa?mann wrote:
> Hi,
>
> On Wed, 20 Dec 2017 14:29:25 +0100 Stefan Riedmueller wrote:
>> From: Christian Hemp <c.hemp@phytec.de>
>>
>> Add support for the PHYTEC phyBOARD-Mira Low-Cost Rapid Development Kit
>> with i.MX 6DualLight/Solo with NAND.
>>
> s/phxBOARD/phyBOARD/ in the subject line.
>
>
> Lothar Wa?mann
I'll fix it, thanks.
Stefan
^ permalink raw reply
* [PATCH] crypto: stm32 - Use standard CONFIG name
From: Fabien DESSENNE @ 2017-12-22 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513793972-11173-1-git-send-email-clabbe@baylibre.com>
Hi Corentin
Thank you for the patch.
On 20/12/17 19:19, Corentin Labbe wrote:
> All hardware crypto devices have their CONFIG names using the following
> convention:
> CRYPTO_DEV_name_algo
>
> This patch apply this conventions on STM32 CONFIG names.
>
> Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Reviewed-by: Fabien Dessenne <fabien.dessenne@st.com>
> ---
> drivers/crypto/stm32/Kconfig | 6 +++---
> drivers/crypto/stm32/Makefile | 6 +++---
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/crypto/stm32/Kconfig b/drivers/crypto/stm32/Kconfig
> index 61ef00b6bf45..63aa78c0b12b 100644
> --- a/drivers/crypto/stm32/Kconfig
> +++ b/drivers/crypto/stm32/Kconfig
> @@ -1,4 +1,4 @@
> -config CRC_DEV_STM32
> +config CRYPTO_DEV_STM32_CRC
> tristate "Support for STM32 crc accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> @@ -6,7 +6,7 @@ config CRC_DEV_STM32
> This enables support for the CRC32 hw accelerator which can be found
> on STMicroelectronics STM32 SOC.
>
> -config HASH_DEV_STM32
> +config CRYPTO_DEV_STM32_HASH
> tristate "Support for STM32 hash accelerators"
> depends on ARCH_STM32
> depends on HAS_DMA
> @@ -19,7 +19,7 @@ config HASH_DEV_STM32
> This enables support for the HASH hw accelerator which can be found
> on STMicroelectronics STM32 SOC.
>
> -config CRYP_DEV_STM32
> +config CRYPTO_DEV_STM32_CRYP
> tristate "Support for STM32 cryp accelerators"
> depends on ARCH_STM32
> select CRYPTO_HASH
> diff --git a/drivers/crypto/stm32/Makefile b/drivers/crypto/stm32/Makefile
> index 2c19fc155bfd..53d1bb94b221 100644
> --- a/drivers/crypto/stm32/Makefile
> +++ b/drivers/crypto/stm32/Makefile
> @@ -1,3 +1,3 @@
> -obj-$(CONFIG_CRC_DEV_STM32) += stm32_crc32.o
> -obj-$(CONFIG_HASH_DEV_STM32) += stm32-hash.o
> -obj-$(CONFIG_CRYP_DEV_STM32) += stm32-cryp.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRC) += stm32_crc32.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_HASH) += stm32-hash.o
> +obj-$(CONFIG_CRYPTO_DEV_STM32_CRYP) += stm32-cryp.o
^ permalink raw reply
* [PATCH 0/2] arm64: dts: renesas: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <39b80de4-84bd-916e-2ff9-580f7db720f2@mentor.com>
On Thu, Dec 21, 2017 at 04:57:58PM +0200, Vladimir Zapolskiy wrote:
> Hi Simon,
>
> On 12/21/2017 01:28 PM, Simon Horman wrote:
> > On Wed, Dec 20, 2017 at 03:22:10PM +0200, Vladimir Zapolskiy wrote:
> >> The present change is a bug fix for AVB link iteratively up/down.
> >
> > If this is a bug please consider including Fixes tags in the patches.
> >
>
> would you prefer to get v2 with the Fixes tags added or short replies
> to v1 with the requested information?
Either way would be fine. I see you have gone ahead and posted v2,
lets roll with that.
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-2-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-common.dtsi b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> index 4e800e933944..c3095bd575d7 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/salvator-common.dtsi
> @@ -255,7 +255,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1513869539-18803-3-git-send-email-vladimir_zapolskiy@mentor.com>
On Thu, Dec 21, 2017 at 05:18:59PM +0200, Vladimir Zapolskiy wrote:
> From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
>
> The present change is a bug fix for AVB link iteratively up/down.
>
> Steps to reproduce:
> - start AVB TX stream (Using aplay via MSE),
> - disconnect+reconnect the eth cable,
> - after a reconnection the eth connection goes iteratively up/down
> without user interaction,
> - this may heal after some seconds or even stay for minutes.
>
> As the documentation specifies, the "renesas,no-ether-link" option
> should be used when a board does not provide a proper AVB_LINK signal.
> There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> and ULCB starter kits since the AVB_LINK is correctly handled by HW.
>
> Choosing to keep or remove the "renesas,no-ether-link" option will
> have impact on the code flow in the following ways:
> - keeping this option enabled may lead to unexpected behavior since
> the RX & TX are enabled/disabled directly from adjust_link function
> without any HW interrogation,
> - removing this option, the RX & TX will only be enabled/disabled after
> HW interrogation. The HW check is made through the LMON pin in PSR
> register which specifies AVB_LINK signal value (0 - at low level;
> 1 - at high level).
>
> In conclusion, the present change is also a safety improvement because
> it removes the "renesas,no-ether-link" option leading to a proper way
> of detecting the link state based on HW interrogation and not on
> software heuristic.
>
> Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
The above shuffles the code around but does not introduce the problem
as far as I can see. Instead I think we should use:
Fixes: 144bf6ccb13f ("arm64: dts: h3ulcb: enable EthernetAVB")
Fixes: 883fae315a6a ("arm64: dts: m3ulcb: enable EthernetAVB")
> Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
> ---
> arch/arm64/boot/dts/renesas/ulcb.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/ulcb.dtsi b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> index be91016e0b48..3e7a6b94e9f8 100644
> --- a/arch/arm64/boot/dts/renesas/ulcb.dtsi
> +++ b/arch/arm64/boot/dts/renesas/ulcb.dtsi
> @@ -145,7 +145,6 @@
> &avb {
> pinctrl-0 = <&avb_pins>;
> pinctrl-names = "default";
> - renesas,no-ether-link;
> phy-handle = <&phy0>;
> status = "okay";
>
> --
> 2.8.1
>
^ permalink raw reply
* arm64 crashkernel fails to boot on acpi-only machines due to ACPI regions being no longer mapped as NOMAP
From: AKASHI Takahiro @ 2017-12-22 8:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACi5LpMUnUKxiALAHW9_PE2RYC8GNWLPGpdJ5ca53g=v3rNkfg@mail.gmail.com>
On Thu, Dec 21, 2017 at 05:36:30PM +0530, Bhupesh Sharma wrote:
> Hello Akashi,
>
> On Thu, Dec 21, 2017 at 4:04 PM, AKASHI Takahiro
> <takahiro.akashi@linaro.org> wrote:
> > Bhupesh,
> >
> > Can you test the patch attached below, please?
> >
> > It is intended to retain already-reserved regions (ACPI reclaim memory
> > in this case) in system ram (i.e. memblock.memory) without explicitly
> > exporting them via usable-memory-range.
> > (I still have to figure out what the side-effect of this patch is.)
> >
> > Thanks,
> > -Takahiro AKASHI
> >
> > On Thu, Dec 21, 2017 at 01:30:43AM +0530, Bhupesh Sharma wrote:
> >> On Tue, Dec 19, 2017 at 6:39 PM, Ard Biesheuvel
> >> <ard.biesheuvel@linaro.org> wrote:
> >> > On 19 December 2017 at 07:09, AKASHI Takahiro
> >> > <takahiro.akashi@linaro.org> wrote:
> >> >> On Mon, Dec 18, 2017 at 01:40:09PM +0800, Dave Young wrote:
> >> >>> On 12/15/17 at 05:59pm, AKASHI Takahiro wrote:
> >> >>> > On Wed, Dec 13, 2017 at 12:17:22PM +0000, Ard Biesheuvel wrote:
> >> >>> > > On 13 December 2017 at 12:16, AKASHI Takahiro
> >> >>> > > <takahiro.akashi@linaro.org> wrote:
> >> >>> > > > On Wed, Dec 13, 2017 at 10:49:27AM +0000, Ard Biesheuvel wrote:
> >> >>> > > >> On 13 December 2017 at 10:26, AKASHI Takahiro
> >> >>> > > >> <takahiro.akashi@linaro.org> wrote:
> >> >>> > > >> > Bhupesh, Ard,
> >> >>> > > >> >
> >> >>> > > >> > On Wed, Dec 13, 2017 at 03:21:59AM +0530, Bhupesh Sharma wrote:
> >> >>> > > >> >> Hi Ard, Akashi
> >> >>> > > >> >>
> >> >>> > > >> > (snip)
> >> >>> > > >> >
> >> >>> > > >> >> Looking deeper into the issue, since the arm64 kexec-tools uses the
> >> >>> > > >> >> 'linux,usable-memory-range' dt property to allow crash dump kernel to
> >> >>> > > >> >> identify its own usable memory and exclude, at its boot time, any
> >> >>> > > >> >> other memory areas that are part of the panicked kernel's memory.
> >> >>> > > >> >> (see https://www.kernel.org/doc/Documentation/devicetree/bindings/chosen.txt
> >> >>> > > >> >> , for details)
> >> >>> > > >> >
> >> >>> > > >> > Right.
> >> >>> > > >> >
> >> >>> > > >> >> 1). Now when 'kexec -p' is executed, this node is patched up only
> >> >>> > > >> >> with the crashkernel memory range:
> >> >>> > > >> >>
> >> >>> > > >> >> /* add linux,usable-memory-range */
> >> >>> > > >> >> nodeoffset = fdt_path_offset(new_buf, "/chosen");
> >> >>> > > >> >> result = fdt_setprop_range(new_buf, nodeoffset,
> >> >>> > > >> >> PROP_USABLE_MEM_RANGE, &crash_reserved_mem,
> >> >>> > > >> >> address_cells, size_cells);
> >> >>> > > >> >>
> >> >>> > > >> >> (see https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/tree/kexec/arch/arm64/kexec-arm64.c#n465
> >> >>> > > >> >> , for details)
> >> >>> > > >> >>
> >> >>> > > >> >> 2). This excludes the ACPI reclaim regions irrespective of whether
> >> >>> > > >> >> they are marked as System RAM or as RESERVED. As,
> >> >>> > > >> >> 'linux,usable-memory-range' dt node is patched up only with
> >> >>> > > >> >> 'crash_reserved_mem' and not 'system_memory_ranges'
> >> >>> > > >> >>
> >> >>> > > >> >> 3). As a result when the crashkernel boots up it doesn't find this
> >> >>> > > >> >> ACPI memory and crashes while trying to access the same:
> >> >>> > > >> >>
> >> >>> > > >> >> # kexec -p /boot/vmlinuz-`uname -r` --initrd=/boot/initramfs-`uname
> >> >>> > > >> >> -r`.img --reuse-cmdline -d
> >> >>> > > >> >>
> >> >>> > > >> >> [snip..]
> >> >>> > > >> >>
> >> >>> > > >> >> Reserved memory range
> >> >>> > > >> >> 000000000e800000-000000002e7fffff (0)
> >> >>> > > >> >>
> >> >>> > > >> >> Coredump memory ranges
> >> >>> > > >> >> 0000000000000000-000000000e7fffff (0)
> >> >>> > > >> >> 000000002e800000-000000003961ffff (0)
> >> >>> > > >> >> 0000000039d40000-000000003ed2ffff (0)
> >> >>> > > >> >> 000000003ed60000-000000003fbfffff (0)
> >> >>> > > >> >> 0000001040000000-0000001ffbffffff (0)
> >> >>> > > >> >> 0000002000000000-0000002ffbffffff (0)
> >> >>> > > >> >> 0000009000000000-0000009ffbffffff (0)
> >> >>> > > >> >> 000000a000000000-000000affbffffff (0)
> >> >>> > > >> >>
> >> >>> > > >> >> 4). So if we revert Ard's patch or just comment the fixing up of the
> >> >>> > > >> >> memory cap'ing passed to the crash kernel inside
> >> >>> > > >> >> 'arch/arm64/mm/init.c' (see below):
> >> >>> > > >> >>
> >> >>> > > >> >> static void __init fdt_enforce_memory_region(void)
> >> >>> > > >> >> {
> >> >>> > > >> >> struct memblock_region reg = {
> >> >>> > > >> >> .size = 0,
> >> >>> > > >> >> };
> >> >>> > > >> >>
> >> >>> > > >> >> of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >> >>> > > >> >>
> >> >>> > > >> >> if (reg.size)
> >> >>> > > >> >> //memblock_cap_memory_range(reg.base, reg.size); /*
> >> >>> > > >> >> comment this out */
> >> >>> > > >> >> }
> >> >>> > > >> >
> >> >>> > > >> > Please just don't do that. It can cause a fatal damage on
> >> >>> > > >> > memory contents of the *crashed* kernel.
> >> >>> > > >> >
> >> >>> > > >> >> 5). Both the above temporary solutions fix the problem.
> >> >>> > > >> >>
> >> >>> > > >> >> 6). However exposing all System RAM regions to the crashkernel is not
> >> >>> > > >> >> advisable and may cause the crashkernel or some crashkernel drivers to
> >> >>> > > >> >> fail.
> >> >>> > > >> >>
> >> >>> > > >> >> 6a). I am trying an approach now, where the ACPI reclaim regions are
> >> >>> > > >> >> added to '/proc/iomem' separately as ACPI reclaim regions by the
> >> >>> > > >> >> kernel code and on the other hand the user-space 'kexec-tools' will
> >> >>> > > >> >> pick up the ACPI reclaim regions from '/proc/iomem' and add it to the
> >> >>> > > >> >> dt node 'linux,usable-memory-range'
> >> >>> > > >> >
> >> >>> > > >> > I still don't understand why we need to carry over the information
> >> >>> > > >> > about "ACPI Reclaim memory" to crash dump kernel. In my understandings,
> >> >>> > > >> > such regions are free to be reused by the kernel after some point of
> >> >>> > > >> > initialization. Why does crash dump kernel need to know about them?
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >> Not really. According to the UEFI spec, they can be reclaimed after
> >> >>> > > >> the OS has initialized, i.e., when it has consumed the ACPI tables and
> >> >>> > > >> no longer needs them. Of course, in order to be able to boot a kexec
> >> >>> > > >> kernel, those regions needs to be preserved, which is why they are
> >> >>> > > >> memblock_reserve()'d now.
> >> >>> > > >
> >> >>> > > > For my better understandings, who is actually accessing such regions
> >> >>> > > > during boot time, uefi itself or efistub?
> >> >>> > > >
> >> >>> > >
> >> >>> > > No, only the kernel. This is where the ACPI tables are stored. For
> >> >>> > > instance, on QEMU we have
> >> >>> > >
> >> >>> > > ACPI: RSDP 0x0000000078980000 000024 (v02 BOCHS )
> >> >>> > > ACPI: XSDT 0x0000000078970000 000054 (v01 BOCHS BXPCFACP 00000001
> >> >>> > > 01000013)
> >> >>> > > ACPI: FACP 0x0000000078930000 00010C (v05 BOCHS BXPCFACP 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: DSDT 0x0000000078940000 0011DA (v02 BOCHS BXPCDSDT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: APIC 0x0000000078920000 000140 (v03 BOCHS BXPCAPIC 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: GTDT 0x0000000078910000 000060 (v02 BOCHS BXPCGTDT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: MCFG 0x0000000078900000 00003C (v01 BOCHS BXPCMCFG 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: SPCR 0x00000000788F0000 000050 (v02 BOCHS BXPCSPCR 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > > ACPI: IORT 0x00000000788E0000 00007C (v00 BOCHS BXPCIORT 00000001
> >> >>> > > BXPC 00000001)
> >> >>> > >
> >> >>> > > covered by
> >> >>> > >
> >> >>> > > efi: 0x0000788e0000-0x00007894ffff [ACPI Reclaim Memory ...]
> >> >>> > > ...
> >> >>> > > efi: 0x000078970000-0x00007898ffff [ACPI Reclaim Memory ...]
> >> >>> >
> >> >>> > OK. I mistakenly understood those regions could be freed after exiting
> >> >>> > UEFI boot services.
> >> >>> >
> >> >>> > >
> >> >>> > > >> So it seems that kexec does not honour the memblock_reserve() table
> >> >>> > > >> when booting the next kernel.
> >> >>> > > >
> >> >>> > > > not really.
> >> >>> > > >
> >> >>> > > >> > (In other words, can or should we skip some part of ACPI-related init code
> >> >>> > > >> > on crash dump kernel?)
> >> >>> > > >> >
> >> >>> > > >>
> >> >>> > > >> I don't think so. And the change to the handling of ACPI reclaim
> >> >>> > > >> regions only revealed the bug, not created it (given that other
> >> >>> > > >> memblock_reserve regions may be affected as well)
> >> >>> > > >
> >> >>> > > > As whether we should honor such reserved regions over kexec'ing
> >> >>> > > > depends on each one's specific nature, we will have to take care one-by-one.
> >> >>> > > > As a matter of fact, no information about "reserved" memblocks is
> >> >>> > > > exposed to user space (via proc/iomem).
> >> >>> > > >
> >> >>> > >
> >> >>> > > That is why I suggested (somewhere in this thread?) to not expose them
> >> >>> > > as 'System RAM'. Do you think that could solve this?
> >> >>> >
> >> >>> > Memblock-reserv'ing them is necessary to prevent their corruption and
> >> >>> > marking them under another name in /proc/iomem would also be good in order
> >> >>> > not to allocate them as part of crash kernel's memory.
> >> >>> >
> >> >>> > But I'm not still convinced that we should export them in useable-
> >> >>> > memory-range to crash dump kernel. They will be accessed through
> >> >>> > acpi_os_map_memory() and so won't be required to be part of system ram
> >> >>> > (or memblocks), I guess.
> >> >>> > -> Bhupesh?
> >> >>>
> >> >>> I forgot how arm64 kernel retrieve the memory ranges and initialize
> >> >>> them. If no "e820" like interfaces shouldn't kernel reinitialize all
> >> >>> the memory according to the efi memmap? For kdump kernel anything other
> >> >>> than usable memory (which is from the dt node instead) should be
> >> >>> reinitialized according to efi passed info, no?
> >> >>
> >> >> All the regions exported in efi memmap will be added to memblock.memory
> >> >> in (u)efi_init() and then trimmed down to the exact range specified as
> >> >> usable-memory-range by fdt_enforce_memory_region().
> >> >>
> >> >> Now I noticed that the current fdt_enforce_memory_region() may not work well
> >> >> with multiple entries in usable-memory-range.
> >> >>
> >> >
> >> > In any case, the root of the problem is that memory regions lose their
> >> > 'memory' annotation due to the way the memory map is mangled before
> >> > being supplied to the kexec kernel.
> >> >
> >> > Would it be possible to classify all memory that we want to hide from
> >> > the kexec kernel as NOMAP instead? That way, it will not be mapped
> >> > implicitly, but will still be mapped cacheable by acpi_os_ioremap(),
> >> > so this seems to be the most appropriate way to deal with the host
> >> > kernel's memory contents.
> >>
> >> Hmm. wouldn't appending the acpi reclaim regions to
> >> 'linux,usable-memory-range' in the dtb being passed to the crashkernel
> >> be better? Because its indirectly achieving a similar objective
> >> (although may be a subset of all System RAM regions on the primary
> >> kernel's memory).
> >>
> >> I am not aware of the background about the current kexec-tools
> >> implementation where we add only the crashkernel range to the dtb
> >> being passed to the crashkernel.
> >>
> >> Probably Akashi can answer better, as to how we arrived at this design
> >> approach and why we didn't want to expose all System RAM regions (i.e.
> >> ! NOMPAP regions) to the crashkernel.
> >>
> >> I am suspecting that some issues were seen/meet when the System RAM (!
> >> NOMAP regions) were exposed to the crashkernel, and that's why we
> >> finalized on this design approach, but this is something which is just
> >> my guess.
> >>
> >> Regards,
> >> Bhupesh
> >>
> >> >>> >
> >> >>> > Just FYI, on x86, ACPI tables seems to be exposed to crash dump kernel
> >> >>> > via a kernel command line parameter, "memmap=".
> >> >>>
> >> >>> memmap= is only used in old kexec-tools, now we are passing them via
> >> >>> e820 table.
> >> >>
> >> >> Thanks. I remember that you have explained it before.
> >> >>
> >> >> -Takahiro AKASHI
> >> >>
> >> >>> [snip]
> >> >>>
> >> >>> Thanks
> >> >>> Dave
> >
> > ===8<==
> > From 74e2451fea83d546feae76160ba7de426913fe03 Mon Sep 17 00:00:00 2001
> > From: AKASHI Takahiro <takahiro.akashi@linaro.org>
> > Date: Thu, 21 Dec 2017 19:14:23 +0900
> > Subject: [PATCH] arm64: kdump: mark unusable memory as NOMAP
> >
> > ---
> > arch/arm64/mm/init.c | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> > index 00e7b900ca41..8175db94257b 100644
> > --- a/arch/arm64/mm/init.c
> > +++ b/arch/arm64/mm/init.c
> > @@ -352,11 +352,17 @@ static void __init fdt_enforce_memory_region(void)
> > struct memblock_region reg = {
> > .size = 0,
> > };
> > + u64 idx;
> > + phys_addr_t start, end;
> >
> > of_scan_flat_dt(early_init_dt_scan_usablemem, ®);
> >
> > - if (reg.size)
> > - memblock_cap_memory_range(reg.base, reg.size);
> > + if (reg.size) {
> > + for_each_free_mem_range(idx, NUMA_NO_NODE, MEMBLOCK_NONE,
> > + &start, &end, NULL)
> > + memblock_mark_nomap(start, end - start);
> > + memblock_clear_nomap(reg.base, reg.size);
> > + }
> > }
> >
> > void __init arm64_memblock_init(void)
> > --
> > 2.15.1
> >
>
> Thanks for the patch. After applying this on top of
> 4.15.0-rc4-next-20171220, there seems to be a improvement and the
> crashkernel boot no longer hangs while trying to access the acpi
> tables.
>
> However I notice a minor issue. Please see the log below for
> reference, the following message keeps spamming the console but I see
> the crashkernel boot proceed further.:
>
> [ 0.000000] ACPI: NUMA: SRAT: PXM 3 -> MPIDR 0x70303 -> Node 3
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x00000000-0x3fffffff]
> [ 0.000000] ACPI: SRAT: Node 1 PXM 1 [mem 0x2000000000-0x2fffffffff]
> [ 0.000000] ACPI: SRAT: Node 0 PXM 0 [mem 0x1000000000-0x1fffffffff]
> [ 0.000000] ACPI: SRAT: Node 3 PXM 3 [mem 0xa000000000-0xafffffffff]
> [ 0.000000] ACPI: SRAT: Node 2 PXM 2 [mem 0x9000000000-0x9fffffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffe200-0x1ffbffffff]
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffc400-0x1ffbffe1ff]
> [ 0.000000] NUMA: NODE_DATA(1) on node 0
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbffa600-0x1ffbffc3ff]
> [ 0.000000] NUMA: NODE_DATA(2) on node 0
> [ 0.000000] NUMA: NODE_DATA [mem 0x1ffbff8800-0x1ffbffa5ff]
> [ 0.000000] NUMA: NODE_DATA(3) on node 0
> [ 0.000000] [ffff7fe008000000-ffff7fe00800ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008010000-ffff7fe00801ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008020000-ffff7fe00802ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008030000-ffff7fe00803ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008040000-ffff7fe00804ffff] potential offnode
> page_structs
> [ 0.000000] [ffff7fe008050000-ffff7fe00805ffff] potential offnode
> page_structs
>
> [snip..]
> [ 0.000000] [ffff7fe0081f0000-ffff7fe0081fffff] potential offnode
> page_structs
These messages shows that some "struct page" data are allocated on remote
(numa) nodes.
Since on your crash dump kernel, all the usable system memory (starting
0x0e800000) belongs to Node#0, we can't avoid such non-local allocations.
In my best guess, you can ingore them except for some performance penality.
This may be one side-effect.
So does your crash dump kernel now boot successfully?
Thanks,
-Takahiro AKASHI
> This WARNING message seems to come from vmemmap_verify() inside
> 'mm/sparse-vmemmap.c'
>
> Regards,
> Bhupesh
^ permalink raw reply
* [PATCH v2] ARM: dts: sunxi: Add sid for a83t
From: Maxime Ripard @ 2017-12-22 8:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221190903.56ebae536acf51401c63802c@bidouilliste.com>
On Thu, Dec 21, 2017 at 07:09:03PM +0100, Emmanuel Vadot wrote:
>
> Hi Maxime,
>
> On Thu, 21 Dec 2017 16:26:30 +0100
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > Hi,
> >
> > On Thu, Dec 21, 2017 at 09:19:24AM -0600, Kyle Evans wrote:
> > > On Thu, Dec 21, 2017 at 8:55 AM, Maxime Ripard
> > > <maxime.ripard@free-electrons.com> wrote:
> > > > Hi Kyle,
> > > >
> > > > On Tue, Dec 19, 2017 at 03:05:23PM -0600, kevans91 at ksu.edu wrote:
> > > >> Allwinner a83t has a 1 KB sid block with efuse for security rootkey and
> > > >> thermal calibration data, add node to describe it.
> > > >>
> > > >> a83t-sid is not currently supported by nvmem/sunxi-sid, but it is
> > > >> supported in an external driver for FreeBSD.
> > > >>
> > > >> Signed-off-by: Kyle Evans <kevans91@ksu.edu>
> > > >
> > > > The patch looks fine in itself, but we've had a number of issues with
> > > > the register layout (and access patterns) in the past, so I'd rather
> > > > have something that works in Linux too if possible.
> > >
> > > I have a patch that I think should make it work fine on Linux [1], but
> > > I'm afraid I have little to no capability to test it myself and so I
> > > did not add it as well.
> > >
> > > I do know that the rootkey is offset 0x200 into the given space [2],
> > > as is the case with the H3, and that the readout quirk is not needed.
> > > I wasn't 100% sure that the a83t has 2Kbit worth of efuse space as the
> > > H3, but I do know that thermal data can be found at 0x34 and 0x38 in
> > > this space.
> >
> > Then maybe we should leave it aside until someone takes some time on
> > the A83t.
>
> Take some time on the Linux driver and do not apply this patch for
> now you mean ?
Yep.
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: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171222/f9c1e545/attachment.sig>
^ permalink raw reply
* [PATCH v5] arm64: dts: ls1088a: Add USB support
From: yinbo.zhu at nxp.com @ 2017-12-22 8:38 UTC (permalink / raw)
To: linux-arm-kernel
From: yinbo.zhu <yinbo.zhu@nxp.com>
Add USB support on ls1088ardb
Signed-off-by: yinbo zhu <yinbo.zhu@nxp.com>
Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
---
Change in v5:
The usb node was sorted alphabetically in label name.
Remove the point in "yinbo.zhu".
arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts | 8 ++++++++
arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 20 ++++++++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
index 0f6fcda..4f17601 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
@@ -125,3 +125,11 @@
&sata {
status = "okay";
};
+
+&usb0 {
+ status = "okay";
+};
+
+&usb1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
index bd80e9a..caf2bdd 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
@@ -394,6 +394,26 @@
status = "disabled";
};
+ usb0: usb3 at 3100000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3100000 0x0 0x10000>;
+ interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
+ usb1: usb3 at 3110000 {
+ compatible = "snps,dwc3";
+ reg = <0x0 0x3110000 0x0 0x10000>;
+ interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
+ dr_mode = "host";
+ snps,quirk-frame-length-adjustment = <0x20>;
+ snps,dis_rxdet_inp3_quirk;
+ status = "disabled";
+ };
+
sata: sata at 3200000 {
compatible = "fsl,ls1088a-ahci";
reg = <0x0 0x3200000 0x0 0x10000>,
--
1.7.1
^ permalink raw reply related
* linux-next: manual merge of the samsung-krzk tree with the keystone tree
From: Krzysztof Kozlowski @ 2017-12-22 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222100513.79b0d3c6@canb.auug.org.au>
On Fri, Dec 22, 2017 at 12:05 AM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> On Mon, 4 Dec 2017 09:45:58 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>> Today's linux-next merge of the samsung-krzk tree got a conflict in:
>>
>> arch/arm/configs/multi_v7_defconfig
>>
>> between commit:
>>
>> f15187dcdbcd ("ARM: config: sync multi-v7 config with keystone peripherals")
>>
>> from the keystone tree and commit:
>>
>> 453c63073185 ("ARM: multi_v7_defconfig: Enable missing drivers for supported Exynos boards")
>>
>> from the samsung-krzk tree.
>>
>> I fixed it up (see below) and can carry the fix as necessary. This
>> is now fixed as far as linux-next is concerned, but any non trivial
>> conflicts should be mentioned to your upstream maintainer when your tree
>> is submitted for merging. You may also want to consider cooperating
>> with the maintainer of the conflicting tree to minimise any particularly
>> complex conflicts.
>>
>> diff --cc arch/arm/configs/multi_v7_defconfig
>> index 6f2343e259f7,833892568d31..000000000000
>> --- a/arch/arm/configs/multi_v7_defconfig
>> +++ b/arch/arm/configs/multi_v7_defconfig
>> @@@ -558,7 -583,8 +559,9 @@@ CONFIG_VIDEO_STI_DELTA=
>> CONFIG_VIDEO_RENESAS_JPU=m
>> CONFIG_VIDEO_RENESAS_VSP1=m
>> CONFIG_V4L_TEST_DRIVERS=y
>> +CONFIG_VIDEO_VIVID=m
>> + CONFIG_CEC_PLATFORM_DRIVERS=y
>> + CONFIG_VIDEO_SAMSUNG_S5P_CEC=m
>> # CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
>> CONFIG_VIDEO_ADV7180=m
>> CONFIG_VIDEO_ML86V7667=m
>> @@@ -582,16 -613,12 +585,17 @@@ CONFIG_DRM_RCAR_DU=
>> CONFIG_DRM_RCAR_LVDS=y
>> CONFIG_DRM_SUN4I=m
>> CONFIG_DRM_TEGRA=y
>> +CONFIG_DRM_PANEL_SIMPLE=y
>> CONFIG_DRM_PANEL_SAMSUNG_LD9040=m
>> CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
>> -CONFIG_DRM_PANEL_SIMPLE=y
>> +CONFIG_DRM_DUMB_VGA_DAC=m
>> +CONFIG_DRM_NXP_PTN3460=m
>> +CONFIG_DRM_PARADE_PS8622=m
>> +CONFIG_DRM_I2C_ADV7511=m
>> +CONFIG_DRM_I2C_ADV7511_AUDIO=y
>> + CONFIG_DRM_SII9234=m
>> CONFIG_DRM_STI=m
>> -CONFIG_DRM_VC4=y
>> +CONFIG_DRM_VC4=m
>> CONFIG_FB_ARMCLCD=y
>> CONFIG_FB_EFI=y
>> CONFIG_FB_WM8505=y
>> @@@ -626,9 -655,10 +630,10 @@@ CONFIG_SND_SOC_SAMSUNG=
>> CONFIG_SND_SOC_SAMSUNG_SMDK_WM8994=m
>> CONFIG_SND_SOC_SMDK_WM8994_PCM=m
>> CONFIG_SND_SOC_SNOW=m
>> + CONFIG_SND_SOC_ODROID=m
>> CONFIG_SND_SOC_SH4_FSI=m
>> CONFIG_SND_SOC_RCAR=m
>> -CONFIG_SND_SIMPLE_SCU_CARD=m
>> +CONFIG_SND_SOC_STI=m
>> CONFIG_SND_SUN4I_CODEC=m
>> CONFIG_SND_SOC_TEGRA=m
>> CONFIG_SND_SOC_TEGRA20_I2S=m
>
> This is now a conflict between the arm-soc and keystone trees (I think).
Yes, my pull request ended in arm-soc so the same resolution of yours applies.
Thanks!
Krzysztof
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: renesas: salvator-x: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222083203.h5a65uitv7yok5fz@verge.net.au>
On Fri, Dec 22, 2017 at 09:32:03AM +0100, Simon Horman wrote:
> On Thu, Dec 21, 2017 at 05:18:58PM +0200, Vladimir Zapolskiy wrote:
> > From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> >
> > The present change is a bug fix for AVB link iteratively up/down.
> >
> > Steps to reproduce:
> > - start AVB TX stream (Using aplay via MSE),
> > - disconnect+reconnect the eth cable,
> > - after a reconnection the eth connection goes iteratively up/down
> > without user interaction,
> > - this may heal after some seconds or even stay for minutes.
> >
> > As the documentation specifies, the "renesas,no-ether-link" option
> > should be used when a board does not provide a proper AVB_LINK signal.
> > There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> >
> > Choosing to keep or remove the "renesas,no-ether-link" option will
> > have impact on the code flow in the following ways:
> > - keeping this option enabled may lead to unexpected behavior since
> > the RX & TX are enabled/disabled directly from adjust_link function
> > without any HW interrogation,
> > - removing this option, the RX & TX will only be enabled/disabled after
> > HW interrogation. The HW check is made through the LMON pin in PSR
> > register which specifies AVB_LINK signal value (0 - at low level;
> > 1 - at high level).
> >
> > In conclusion, the present change is also a safety improvement because
> > it removes the "renesas,no-ether-link" option leading to a proper way
> > of detecting the link state based on HW interrogation and not on
> > software heuristic.
> >
> > Fixes: d25e8ff0d5aa ("arm64: dts: renesas: Extract common Salvator-X board support")
>
> The above shuffles the code around but does not introduce the problem
> as far as I can see. Instead I think we should use:
>
> Fixes: dc36965a8905 ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
> Fixes: 6fa501c549aa ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
>
> > Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
I have applied this a fix for v4.15 with the updated Fixes tags above.
^ permalink raw reply
* [PATCH v2 2/2] arm64: dts: renesas: ulcb: Remove renesas,no-ether-link property
From: Simon Horman @ 2017-12-22 8:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222083256.2jgts6mdmssr7y76@verge.net.au>
On Fri, Dec 22, 2017 at 09:32:56AM +0100, Simon Horman wrote:
> On Thu, Dec 21, 2017 at 05:18:59PM +0200, Vladimir Zapolskiy wrote:
> > From: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> >
> > The present change is a bug fix for AVB link iteratively up/down.
> >
> > Steps to reproduce:
> > - start AVB TX stream (Using aplay via MSE),
> > - disconnect+reconnect the eth cable,
> > - after a reconnection the eth connection goes iteratively up/down
> > without user interaction,
> > - this may heal after some seconds or even stay for minutes.
> >
> > As the documentation specifies, the "renesas,no-ether-link" option
> > should be used when a board does not provide a proper AVB_LINK signal.
> > There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
> > and ULCB starter kits since the AVB_LINK is correctly handled by HW.
> >
> > Choosing to keep or remove the "renesas,no-ether-link" option will
> > have impact on the code flow in the following ways:
> > - keeping this option enabled may lead to unexpected behavior since
> > the RX & TX are enabled/disabled directly from adjust_link function
> > without any HW interrogation,
> > - removing this option, the RX & TX will only be enabled/disabled after
> > HW interrogation. The HW check is made through the LMON pin in PSR
> > register which specifies AVB_LINK signal value (0 - at low level;
> > 1 - at high level).
> >
> > In conclusion, the present change is also a safety improvement because
> > it removes the "renesas,no-ether-link" option leading to a proper way
> > of detecting the link state based on HW interrogation and not on
> > software heuristic.
> >
> > Fixes: 253ed045a34d ("arm64: dts: renesas: Extract common ULCB board support")
>
> The above shuffles the code around but does not introduce the problem
> as far as I can see. Instead I think we should use:
>
> Fixes: 144bf6ccb13f ("arm64: dts: h3ulcb: enable EthernetAVB")
> Fixes: 883fae315a6a ("arm64: dts: m3ulcb: enable EthernetAVB")
>
> > Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
> > Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
I have applied this a fix for v4.15 with the updated Fixes tags above.
^ permalink raw reply
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Corentin Labbe @ 2017-12-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222065724.GA27149@gondor.apana.org.au>
On Fri, Dec 22, 2017 at 05:57:24PM +1100, Herbert Xu wrote:
> On Wed, Nov 29, 2017 at 09:41:18AM +0100, Corentin Labbe wrote:
> > The crypto engine could actually only enqueue hash and ablkcipher request.
> > This patch permit it to enqueue any type of crypto_async_request.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
>
> This is going the wrong way. We do not want to expose any of the
> base types such as crypto_alg, crypto_async_request to end-users
> and that includes drivers. Only core API code should touch these
> base types.
>
Hello
It's you that was suggesting using crypto_async_request:
https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
"The only wart with this scheme is that the drivers end up seeing
struct crypto_async_request and will need to convert that to the
respective request types but I couldn't really find a better way."
So I wait for any suggestion.
Regards
Corentin Labbe
^ permalink raw reply
* [PATCH] ARM: dts: tango4: remove bogus interrupt-controller property
From: Marc Gonzalez @ 2017-12-22 8:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171221214831.3859194-1-arnd@arndb.de>
On 21/12/2017 22:48, Arnd Bergmann wrote:
> dtc points out that the parent node of the interrupt controllers is not
> actually an interrupt controller itself, and lacks an #interrupt-cells
> property:
>
> arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller at 6e000
>
> This removes the annotation.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/boot/dts/tango4-common.dtsi | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/tango4-common.dtsi b/arch/arm/boot/dts/tango4-common.dtsi
> index 0ec1b0a317b4..ff72a8efb73d 100644
> --- a/arch/arm/boot/dts/tango4-common.dtsi
> +++ b/arch/arm/boot/dts/tango4-common.dtsi
> @@ -156,7 +156,6 @@
> reg = <0x6e000 0x400>;
> ranges = <0 0x6e000 0x400>;
> interrupt-parent = <&gic>;
> - interrupt-controller;
> #address-cells = <1>;
> #size-cells = <1>;
>
Acked-by: Marc Gonzalez <marc_gonzalez@sigmadesigns.com>
Thanks Arnd.
^ permalink raw reply
* [PATCH 4.4 13/78] ARM: Hide finish_arch_post_lock_switch() from modules
From: Greg Kroah-Hartman @ 2017-12-22 8:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222084556.909780563@linuxfoundation.org>
4.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <rostedt@goodmis.org>
commit ef0491ea17f8019821c7e9c8e801184ecf17f85a upstream.
The introduction of switch_mm_irqs_off() brought back an old bug
regarding the use of preempt_enable_no_resched:
As part of:
62b94a08da1b ("sched/preempt: Take away preempt_enable_no_resched() from modules")
the definition of preempt_enable_no_resched() is only available in
built-in code, not in loadable modules, so we can't generally use
it from header files.
However, the ARM version of finish_arch_post_lock_switch()
calls preempt_enable_no_resched() and is defined as a static
inline function in asm/mmu_context.h. This in turn means we cannot
include asm/mmu_context.h from modules.
With today's tip tree, asm/mmu_context.h gets included from
linux/mmu_context.h, which is normally the exact pattern one would
expect, but unfortunately, linux/mmu_context.h can be included from
the vhost driver that is a loadable module, now causing this compile
time error with modular configs:
In file included from ../include/linux/mmu_context.h:4:0,
from ../drivers/vhost/vhost.c:18:
../arch/arm/include/asm/mmu_context.h: In function 'finish_arch_post_lock_switch':
../arch/arm/include/asm/mmu_context.h:88:3: error: implicit declaration of function 'preempt_enable_no_resched' [-Werror=implicit-function-declaration]
preempt_enable_no_resched();
Andy already tried to fix the bug by including linux/preempt.h
from asm/mmu_context.h, but that didn't help. Arnd suggested reordering
the header files, which wasn't popular, so let's use this
workaround instead:
The finish_arch_post_lock_switch() definition is now also hidden
inside of #ifdef MODULE, so we don't see anything referencing
preempt_enable_no_resched() from a header file. I've built a
few hundred randconfig kernels with this, and did not see any
new problems.
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Russell King - ARM Linux <linux@armlinux.org.uk>
Cc: Stephane Eranian <eranian@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vince Weaver <vincent.weaver@maine.edu>
Cc: linux-arm-kernel at lists.infradead.org
Fixes: f98db6013c55 ("sched/core: Add switch_mm_irqs_off() and use it in the scheduler")
Link: http://lkml.kernel.org/r/1463146234-161304-1-git-send-email-arnd at arndb.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/include/asm/mmu_context.h | 2 ++
1 file changed, 2 insertions(+)
--- a/arch/arm/include/asm/mmu_context.h
+++ b/arch/arm/include/asm/mmu_context.h
@@ -61,6 +61,7 @@ static inline void check_and_switch_cont
cpu_switch_mm(mm->pgd, mm);
}
+#ifndef MODULE
#define finish_arch_post_lock_switch \
finish_arch_post_lock_switch
static inline void finish_arch_post_lock_switch(void)
@@ -82,6 +83,7 @@ static inline void finish_arch_post_lock
preempt_enable_no_resched();
}
}
+#endif /* !MODULE */
#endif /* CONFIG_MMU */
^ permalink raw reply
* [PATCH v2] ARM: dts: Add TVE/TVC and ILI9322 panel to DIR-685
From: Linus Walleij @ 2017-12-22 8:51 UTC (permalink / raw)
To: linux-arm-kernel
This adds the TVE200/TVC TV-encoder and the Ilitek ILI9322 panel
to the DIR-685 device tree.
This brings graphics to this funky router and it is possible to
even run a console on its tiny screen.
Incidentally this requires us to disable the access to the
parallel (NOR) flash, as the communication pins to the panel
are shared with the flash memory.
To access the flash, a separate kernel with the panel disabled
and the flash enabled should be booted. The pin control selecting
whether to use the lines cannot be altered at runtime due to
hardware constraints.
Cc: David Lechner <david@lechnology.com>
Cc: Stefano Babic <sbabic@denx.de>
Cc: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
ChangeLog v1->v2:
- Rename node from "tvc" to "display-controller"
- Drop all the surplus device tree config that we are now
instead open coding in the driver, as per the request of
the DT maintainers.
- Tested on the D-Link DIR-685.
---
arch/arm/boot/dts/gemini-dlink-dir-685.dts | 63 +++++++++++++++++++++++++++++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/gemini-dlink-dir-685.dts b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
index e75e2d44371c..0a86b784cf7f 100644
--- a/arch/arm/boot/dts/gemini-dlink-dir-685.dts
+++ b/arch/arm/boot/dts/gemini-dlink-dir-685.dts
@@ -45,6 +45,47 @@
};
};
+ vdisp: regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "display-power";
+ regulator-min-microvolt = <3600000>;
+ regulator-max-microvolt = <3600000>;
+ /* Collides with LCD E */
+ gpio = <&gpio0 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* Collides with IDE pins, that's cool (we do not use them) */
+ gpio-sck = <&gpio1 5 GPIO_ACTIVE_HIGH>;
+ gpio-miso = <&gpio1 8 GPIO_ACTIVE_HIGH>;
+ gpio-mosi = <&gpio1 7 GPIO_ACTIVE_HIGH>;
+ /* Collides with pflash CE1, not so cool */
+ cs-gpios = <&gpio0 20 GPIO_ACTIVE_HIGH>;
+ num-chipselects = <1>;
+
+ panel: display at 0 {
+ compatible = "dlink,dir-685-panel", "ilitek,ili9322";
+ reg = <0>;
+ /* 50 ns min period = 20 MHz */
+ spi-max-frequency = <20000000>;
+ spi-cpol; /* Clock active low */
+ vcc-supply = <&vdisp>;
+ iovcc-supply = <&vdisp>;
+ vci-supply = <&vdisp>;
+
+ port {
+ panel_in: endpoint {
+ remote-endpoint = <&display_out>;
+ };
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
led-wps {
@@ -115,7 +156,16 @@
soc {
flash at 30000000 {
- status = "okay";
+ /*
+ * Flash access is by default disabled, because it
+ * collides with the Chip Enable signal for the display
+ * panel, that reuse the parallel flash Chip Select 1
+ * (CS1). Enabling flash makes graphics stop working.
+ *
+ * We might be able to hack around this by letting
+ * GPIO poke around in the flash controller registers.
+ */
+ /* status = "okay"; */
/* 32MB of flash */
reg = <0x30000000 0x02000000>;
@@ -242,5 +292,16 @@
ata at 63000000 {
status = "okay";
};
+
+ display-controller at 6a000000 {
+ status = "okay";
+
+ port at 0 {
+ reg = <0>;
+ display_out: endpoint {
+ remote-endpoint = <&panel_in>;
+ };
+ };
+ };
};
};
--
2.14.3
^ permalink raw reply related
* [PATCH RFC 1/4] crypto: engine - Permit to enqueue all async requests
From: Herbert Xu @ 2017-12-22 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171222084148.GA3024@Red>
On Fri, Dec 22, 2017 at 09:41:48AM +0100, Corentin Labbe wrote:
>
> It's you that was suggesting using crypto_async_request:
> https://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1474434.html
> "The only wart with this scheme is that the drivers end up seeing
> struct crypto_async_request and will need to convert that to the
> respective request types but I couldn't really find a better way."
>
> So I wait for any suggestion.
The core engine code obviously will use the base type but it should
not be exposed to the driver authors. IOW all exposed API should
take the final types such as aead_request before casting it.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ 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