* [PATCH] imx6: fix pcie enumeration
From: Lorenzo Pieralisi @ 2018-01-05 17:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ebf30c78-b772-6214-f441-c86ae7fdba7e@ncentric.com>
On Fri, Jan 05, 2018 at 02:39:57PM +0100, Koen Vandeputte wrote:
>
>
> On 2018-01-05 13:32, Lorenzo Pieralisi wrote:
> >
> >> /* setup bus numbers */
> >> val = dw_pcie_readl_dbi
> >> val &= 0xff000000;
> >> val |= 0x00010100; <--- hardcoded today
> >> dw_pcie_writel_dbi
>
> >>I *think* I understand what's going on - the kernel takes the primary,
> >>secondary and subordinate values in the host bridge as valid in:
> >>
> >>pci_scan_bridge_extend()
> >>
> >>and given that pcibios_assign_all_busses() returns false (guess) it sets-up
> >>the bus hierarchy with a bus resource with subordinate number as read from
> >>PCI host bridge config space - which, given that it is 1 according to your
> >>explanation - this triggers the issue you reported.
> >>
> >>After commit a20c7f36bd3d the root bus resource is propagated down the
> >>hierarchy, hence the problem.
> >>
> >>So, in order to fix the issue I think the best way is to programme the
> >>root bridge in:
> >>
> >>drivers/pci/dwc/pci-designware-host.c
> >>
> >>but with the value coming from the root bus IORESOURCE_BUS resource,
> >>not hardcoding 0xff.
> >>
> >>I would kindly ask you to send logs with debug turned on in:
> >>
> >>drivers/pci/probe.c
> >>
> >>since I would like to check my understanding is correct.
> >>
> >>Please CC all dwc host maintainers since this has potential widespread
> >>impact.
> >>
> >>Thanks,
> >>Lorenzo
> Hi Lorenzo,
>
> This is exactly what I'm trying to explain:
>
> The host starts of with a (hardcoded today) subord of 1. [bits 16:23]
>
> Since commit a20c7f36bd3d, downstream devices cannot assign bus nr's
> higher than the subord of the upstream device.
> So in this case, scanning stops after the bridge as soon as bus 1 is
> assigned .. :)
There is one thing that I need to understand though. Before the commit
above, how would enumeration works given that the subordinate bus number
was set to 1 and that the kernel, AFAICS, does not overwrite it ?
Are you able to send me a log (enumeration with debugging enabled and
lspci) with the commit above reverted please ?
Thanks,
Lorenzo
> As other targets besides i.MX6 (layerscape, armada8k, ...) also use
> the same function to init PCIe, I believe those targets are also
> affected.
>
> I've tested here setting the PCI_PRIMARY_BUS register to 0x 00 ff 01
> 00? (ignored-subord-secbus-primbus), and the whole scanning works
> again.
> I fully agree that hardcoding is not the final fix, as this param
> can be defined in a DT.
>
>
> Fixing this, combined with the upstream commit exposing the error,
> fixes all following pci boot errors:
>
> ..
> [??? 0.466405] pci_bus 0000:05: [bus 05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
> [??? 0.466435] pci_bus 0000:02: busn_res: can not insert [bus 02-05]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.466454] pci_bus 0000:02: [bus 02-05] partially hidden behind
> bridge 0000:01 [bus 01]
> ..
>
>
> Watching the tree using lspci also shows that all primaries,
> secondaries and subords are perfectly logical as expected.
>
>
> Thanks,
>
> Koen
>
>
> Log showing the initial issue without any fixup:
>
>
> [??? 0.116673] OF: PCI: host bridge /soc/pcie at 0x01000000 ranges:
> [??? 0.116692] OF: PCI:?? No bus range found for
> /soc/pcie at 0x01000000, using [bus 00-ff]
> [??? 0.116719] OF: PCI:??? IO 0x01f80000..0x01f8ffff -> 0x00000000
> [??? 0.116739] OF: PCI:?? MEM 0x01000000..0x01efffff -> 0x01000000
> [??? 0.337752] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337771] imx6q-pcie 1ffc000.pcie: Link: Gen2 disabled
> [??? 0.337785] imx6q-pcie 1ffc000.pcie: link up
> [??? 0.337796] imx6q-pcie 1ffc000.pcie: Link up, Gen1
> [??? 0.338039] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
> [??? 0.338055] pci_bus 0000:00: root bus resource [bus 00-ff]
> [??? 0.338069] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
> [??? 0.338082] pci_bus 0000:00: root bus resource [mem
> 0x01000000-0x01efffff]
> [??? 0.338094] pci_bus 0000:00: scanning bus
> [??? 0.338127] pci 0000:00:00.0: [16c3:abcd] type 01 class 0x060400
> [??? 0.338151] pci 0000:00:00.0: reg 0x10: [mem 0x00000000-0x000fffff]
> [??? 0.338168] pci 0000:00:00.0: reg 0x38: [mem 0x00000000-0x0000ffff pref]
> [??? 0.338204] pci 0000:00:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.338259] pci 0000:00:00.0: supports D1
> [??? 0.338267] pci 0000:00:00.0: PME# supported from D0 D1 D3hot D3cold
> [??? 0.338276] pci 0000:00:00.0: PME# disabled
> [??? 0.338512] pci_bus 0000:00: fixups for bus
> [??? 0.338525] PCI: bus0: Fast back to back transfers disabled
> [??? 0.338541] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> [??? 0.338673] pci_bus 0000:01: scanning bus
> [??? 0.338773] pci 0000:01:00.0: [10b5:8604] type 01 class 0x060400
> [??? 0.338816] pci 0000:01:00.0: calling ventana_pciesw_early_fixup+0x0/0xa4
> [??? 0.467817] pci 0000:01:00.0: reg 0x10: [mem 0x00000000-0x0001ffff]
> [??? 0.467999] pci 0000:01:00.0: calling pci_fixup_ide_bases+0x0/0x4c
> [??? 0.468467] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
> [??? 0.468491] pci 0000:01:00.0: PME# disabled
> [??? 0.468795] pci_bus 0000:01: fixups for bus
> [??? 0.468854] PCI: bus1: Fast back to back transfers disabled
> [??? 0.468877] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 0
> [??? 0.468886] pci 0000:01:00.0: bridge configuration invalid ([bus
> 00-00]), reconfiguring
> [??? 0.468939] pci 0000:01:00.0: scanning [bus 00-00] behind bridge, pass 1
> [??? 0.469265] pci_bus 0000:02: busn_res: can not insert [bus 02-01]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469282] pci_bus 0000:02: scanning bus
> [??? 0.469554] pci_bus 0000:02: fixups for bus
> [??? 0.469559] PCI: bus2: Fast back to back transfers enabled
> [??? 0.469572] pci_bus 0000:02: bus scan returning with max=02
> [??? 0.469582] pci_bus 0000:02: busn_res: [bus 02-01] end is updated to 02
> [??? 0.469593] pci_bus 0000:02: busn_res: can not insert [bus 02]
> under [bus 01] (conflicts with (null) [bus 01])
> [??? 0.469615] pci_bus 0000:02: [bus 02] partially hidden behind
> bridge 0000:01 [bus 01]
> [??? 0.469636] pci_bus 0000:01: bus scan returning with max=02
> [??? 0.469643] pci 0000:00:00.0: bridge has subordinate 01 but max busn 02
> [??? 0.469661] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 1
> [??? 0.469671] pci_bus 0000:00: bus scan returning with max=01
> [??? 0.469791] pci 0000:00:00.0: fixup irq: got 298
> [??? 0.469800] pci 0000:00:00.0: assigning IRQ 298
> [??? 0.469849] pci 0000:01:00.0: fixup irq: got 298
> [??? 0.469856] pci 0000:01:00.0: assigning IRQ 298
> [??? 0.469946] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
> [??? 0.469965] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
> [??? 0.469980] pci 0000:00:00.0: BAR 6: assigned [mem
> 0x01200000-0x0120ffff pref]
> [??? 0.469997] pci 0000:01:00.0: BAR 0: assigned [mem 0x01100000-0x0111ffff]
> [??? 0.470026] pci 0000:01:00.0: PCI bridge to [bus 02]
> [??? 0.470108] pci 0000:00:00.0: PCI bridge to [bus 01]
> [??? 0.470121] pci 0000:00:00.0:?? bridge window [mem 0x01100000-0x011fffff]
> [??? 0.470381] pcieport 0000:00:00.0: Signaling PME through PCIe PME
> interrupt
> [??? 0.470397] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
> [??? 0.470412] pcie_pme 0000:00:00.0:pcie001: service driver pcie_pme loaded
> [??? 0.470660] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
> [??? 0.470788] pcieport 0000:01:00.0: enabling bus mastering
>
>
>
> [ Node 4 | node-4 ] lspci -tv
> -[0000:00]---00.0-[01]----00.0-[02]--
> [ Node 4 | node-4 ]
>
>
>
> [ Node 4 | node-4 ] lspci -v
> 00:00.0 PCI bridge: Synopsys, Inc. Device abcd (rev 01) (prog-if 00
> [Normal decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01000000 (32-bit, non-prefetchable) [size=1M]
> ??? Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: 01100000-011fffff [size=1M]
> ??? Prefetchable memory behind bridge: None
> ??? [virtual] Expansion ROM at 01200000 [disabled] [size=64K]
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
> ??? Capabilities: [70] Express Root Port (Slot-), MSI 00
> ??? Capabilities: [100] Advanced Error Reporting
> ??? Capabilities: [140] Virtual Channel
> ??? Kernel driver in use: pcieport
> lspci: Unable to load libkmod resources: error -12
>
> 01:00.0 PCI bridge: PLX Technology, Inc. PEX 8604 4-lane, 4-Port PCI
> Express Gen 2 (5.0 GT/s) Switch (rev ba) (prog-if 00 [Normal
> decode])
> ??? Flags: bus master, fast devsel, latency 0, IRQ 298
> ??? Memory at 01100000 (32-bit, non-prefetchable) [size=128K]
> ??? Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
> ??? I/O behind bridge: None
> ??? Memory behind bridge: None
> ??? Prefetchable memory behind bridge: None
> ??? Capabilities: [40] Power Management version 3
> ??? Capabilities: [48] MSI: Enable- Count=1/4 Maskable+ 64bit+
> ??? Capabilities: [68] Express Upstream Port, MSI 00
> ??? Capabilities: [a4] Subsystem: PLX Technology, Inc. PEX 8604
> 4-lane, 4-Port PCI Express Gen 2 (5.0 GT/s) Switch
> ??? Capabilities: [100] Device Serial Number ba-86-01-10-b5-df-0e-00
> ??? Capabilities: [fb4] Advanced Error Reporting
> ??? Capabilities: [138] Power Budgeting <?>
> ??? Capabilities: [148] Virtual Channel
> ??? Capabilities: [448] Vendor Specific Information: ID=0000 Rev=0
> Len=0cc <?>
> ??? Capabilities: [950] Vendor Specific Information: ID=0001 Rev=0
> Len=010 <?>
> ??? Kernel driver in use: pcieport
> [ Node 4 | node-4 ]
^ permalink raw reply
* [v2 PATCH 3/6] dt-bindings: usb: mtu3: update USB wakeup properties
From: Rob Herring @ 2018-01-05 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9ded06bb1264f2c05ba7f52ecf1619d5e595d80f.1514967463.git.chunfeng.yun@mediatek.com>
On Wed, Jan 03, 2018 at 04:53:19PM +0800, Chunfeng Yun wrote:
> Add two arguments in "mediatek,syscon-wakeup" to support multi
> wakeup glue layer between SSUSB and SPM, and use standard property
> "wakeup-source" to replace the private "mediatek,enable-wakeup"
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> Documentation/devicetree/bindings/usb/mediatek,mtu3.txt | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Catalin Marinas @ 2018-01-05 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102200549.22984-6-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 10684b17d0bd..b6d51b4d5ce1 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
> f->vendor == (u16) PCI_ANY_ID) &&
> (f->device == dev->device ||
> f->device == (u16) PCI_ANY_ID)) {
> - calltime = fixup_debug_start(dev, f->hook);
> - f->hook(dev);
> - fixup_debug_report(dev, calltime, f->hook);
> + void (*hook)(struct pci_dev *dev);
> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
> + hook = (void *)((unsigned long)&f->hook_offset +
> + f->hook_offset);
> +#else
> + hook = f->hook;
> +#endif
More of a nitpick but I've seen this pattern in several places in your
code, maybe worth defining a macro (couldn't come up with a better
name):
#define offset_to_ptr(off) \
((void *)((unsigned long)&(off) + (off)))
--
Catalin
^ permalink raw reply
* [PATCH v5 1/2] PCI: mediatek: Clear IRQ status after IRQ dispatched to avoid reentry
From: Marc Zyngier @ 2018-01-05 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515153107.25872.57.camel@mhfsdcap03>
On 05/01/18 11:51, Honghui Zhang wrote:
> On Thu, 2018-01-04 at 19:04 +0000, Marc Zyngier wrote:
>> On 04/01/18 18:40, Lorenzo Pieralisi wrote:
>>> [+Marc]
>>>
>>> On Wed, Dec 27, 2017 at 08:59:53AM +0800, honghui.zhang at mediatek.com wrote:
>>>> 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.
>>>
>>> This looks like two different issues that should be fixed with two
>>> patches.
>
> Ok, I split this into two patches and figure out a more reasonable
> approach by using irq_chip solution.
>
>>>
>>>> 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(-)
>>>
>>> For the sake of uniformity, I first want to understand why this
>>> driver does not call:
>>>
>>> chained_irq_enter/exit()
>>>
>>> in the primary handler (mtk_pcie_intr_handler()).
>>>
>>> With the GIC as a primary interrupt controller we have not
>>> even figured out how current code can actually work without
>>> calling the chained_* API.
>>>
>>> I want to come up with a consistent handling of IRQ domains for
>>> all host bridges and any discrepancy should be explained.
>>
>> That's because this driver is a huge hack, see below:
>>
>>>
>>>> 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)
>>
>> This function is not a chained irqchip, but an interrupt handler...
>>
>>>> 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);
>>
>> and nonetheless, this calls into generic_handle_irq(). That's a complete
>> violation of the interrupt layering. Maybe there is a good reason for
>> it, but I'd like to know which one.
>>
>> Which means that all of the ack/mask has to be done outside of the
>> irqchip framework too... Disgusting.
>>
>>>> + /* Clear the INTx */
>>>> + writel(1 << bit, port->base + PCIE_INT_STATUS);
>>>
>>> I think that these masking/acking should actually be done through
>>> the irq_chip hooks (see for instance pci-ftpci100.c) - that would
>>> make this kind of bugs much easier to prevent (because the IRQ
>>> layer does the sequencing for you).
>>
>> +1.
>>
>
> Thanks for your advice, I need to do some homework to have a better
> understanding of the irq_chip approach.
>
>>> Marc (CC'ed) has a more comprehensive view on this than me - I would
>>> like to get to a point where all host bridges uses a consistent
>>> approach for chained IRQ handling and I hope this bug fix can be
>>> a starting point.
>>
>> +1 again. We definitely need to come up with some form of common
>> approach for all these host drivers, and maybe turn that into a library...
>>
>
> Well, this is beyond my knowledge now, I guess I can figure out how to
> using irq_chip for the first step, then I may following this "common
> approach" after we have a solution for that?
We can help you with that at a later time indeed. the urgent thing is to
fix this driver so that it does the right thing, and we can then look at
using a common approach for a number of them.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v7 05/10] PCI: Add support for relative addressing in quirk tables
From: Ard Biesheuvel @ 2018-01-05 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105174112.jk3mvo5qwg7l4vzo@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:41, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:44PM +0000, Ard Biesheuvel wrote:
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 10684b17d0bd..b6d51b4d5ce1 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -3556,9 +3556,16 @@ static void pci_do_fixups(struct pci_dev *dev, struct pci_fixup *f,
>> f->vendor == (u16) PCI_ANY_ID) &&
>> (f->device == dev->device ||
>> f->device == (u16) PCI_ANY_ID)) {
>> - calltime = fixup_debug_start(dev, f->hook);
>> - f->hook(dev);
>> - fixup_debug_report(dev, calltime, f->hook);
>> + void (*hook)(struct pci_dev *dev);
>> +#ifdef CONFIG_HAVE_ARCH_PREL32_RELOCATIONS
>> + hook = (void *)((unsigned long)&f->hook_offset +
>> + f->hook_offset);
>> +#else
>> + hook = f->hook;
>> +#endif
>
> More of a nitpick but I've seen this pattern in several places in your
> code, maybe worth defining a macro (couldn't come up with a better
> name):
>
> #define offset_to_ptr(off) \
> ((void *)((unsigned long)&(off) + (off)))
>
Yeah, good point. Or even
static inline void *offset_to_ptr(const s32 *off)
{
return (void *)((unsigned long)off + *off);
}
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180102200549.22984-8-ard.biesheuvel@linaro.org>
On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> index e12d7d096fc0..7b05b404063a 100644
> --- a/arch/arm/include/asm/jump_label.h
> +++ b/arch/arm/include/asm/jump_label.h
> @@ -45,5 +45,32 @@ struct jump_entry {
> jump_label_t key;
> };
>
> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> +{
> + return entry->code;
> +}
> +
> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> +{
> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> +}
> +
> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> +{
> + return (unsigned long)entry->key & 1UL;
> +}
> +
> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> +{
> + return entry->code == 0;
> +}
> +
> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> +{
> + entry->code = 0;
> +}
> +
> +#define jump_label_swap NULL
Is there any difference between these functions on any of the
architectures touched? Even with the relative offset, arm64 and x86
looked the same to me (well, I may have missed some detail).
--
Catalin
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105175834.vqgpsme7itsdg54u@armageddon.cambridge.arm.com>
On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> index e12d7d096fc0..7b05b404063a 100644
>> --- a/arch/arm/include/asm/jump_label.h
>> +++ b/arch/arm/include/asm/jump_label.h
>> @@ -45,5 +45,32 @@ struct jump_entry {
>> jump_label_t key;
>> };
>>
>> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> +{
>> + return entry->code;
>> +}
>> +
>> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> +{
>> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> +}
>> +
>> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> +{
>> + return (unsigned long)entry->key & 1UL;
>> +}
>> +
>> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> +{
>> + return entry->code == 0;
>> +}
>> +
>> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> +{
>> + entry->code = 0;
>> +}
>> +
>> +#define jump_label_swap NULL
>
> Is there any difference between these functions on any of the
> architectures touched? Even with the relative offset, arm64 and x86
> looked the same to me (well, I may have missed some detail).
>
No, the latter two are identical everywhere, and the others are the
same modulo absolute vs relative.
The issue is that the struct definition is per-arch so the accessors
should be as well. Perhaps I should introduce two variants two
asm-generic, similar to how we have different flavors of unaligned
accessors.
^ permalink raw reply
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Vladimir Zapolskiy @ 2018-01-05 18:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105170959.17266-3-jbrunet@baylibre.com>
Hi Jerome,
On 01/05/2018 07:09 PM, Jerome Brunet wrote:
> When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> register shall be left un-touched, but it does not mean the clock
> should stop rate propagation if CLK_SET_RATE_PARENT is set
>
okay, the statement sounds correct, but there is no such clocks on LPC32xx,
thus I hardly can confirm that adding dead/inapplicable code is a fix.
> This properly handled in qcom clk-regmap-divider but it was not in the
> lpc32xx divider
>
> Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
I would suggest to drop two LPC32xx clock driver changes from the series.
--
With best wishes,
Vladimir
^ permalink raw reply
* [GIT PULL 1/4] soc changes for omaps for v4.16, part 2
From: Tony Lindgren @ 2018-01-05 18:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105065916.snklnojvp5tshpvl@localhost>
* Olof Johansson <olof@lixom.net> [180105 07:38]:
> On Fri, Dec 22, 2017 at 10:14:24AM -0800, Tony Lindgren wrote:
> > From: "Tony Lindgren" <tony@atomide.com>
> > Tony Lindgren (1):
> > ARM: OMAP2+: Drop unused legacy data for prcm_reg_id and module_bit
>
> Nice cleanup. Merged. It had a conflict with an earlier fixes branch, please
> double-check my resolution.
Thanks looks good to me.
Regards,
Tony
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Catalin Marinas @ 2018-01-05 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu8zROE-TDpfbbVi3RPOr8BNcsN_s27Gr-VvMN+-eMU+Hg@mail.gmail.com>
On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
> >> index e12d7d096fc0..7b05b404063a 100644
> >> --- a/arch/arm/include/asm/jump_label.h
> >> +++ b/arch/arm/include/asm/jump_label.h
> >> @@ -45,5 +45,32 @@ struct jump_entry {
> >> jump_label_t key;
> >> };
> >>
> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
> >> +{
> >> + return entry->code;
> >> +}
> >> +
> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
> >> +{
> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
> >> +}
> >> +
> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
> >> +{
> >> + return (unsigned long)entry->key & 1UL;
> >> +}
> >> +
> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
> >> +{
> >> + return entry->code == 0;
> >> +}
> >> +
> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
> >> +{
> >> + entry->code = 0;
> >> +}
> >> +
> >> +#define jump_label_swap NULL
> >
> > Is there any difference between these functions on any of the
> > architectures touched? Even with the relative offset, arm64 and x86
> > looked the same to me (well, I may have missed some detail).
>
> No, the latter two are identical everywhere, and the others are the
> same modulo absolute vs relative.
>
> The issue is that the struct definition is per-arch so the accessors
> should be as well.
Up to this patch, even the jump_entry structure is the same on all
architectures (the jump_label_t type differs).
With relative offset, can you not just define jump_label_t to s32? At a
quick grep in mainline, it doesn't seem to be used outside the structure
definition.
> Perhaps I should introduce two variants two asm-generic, similar to
> how we have different flavors of unaligned accessors.
You could as well define them directly in kernel/jump_label.h or, if
used outside this file, include/linux/jump_label.h.
--
Catalin
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: James Morse @ 2018-01-05 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <43942acd-f6ff-ec58-aafb-a6f3ba40fab9@huawei.com>
Hi gengdongjiu,
On 16/12/17 02:53, gengdongjiu wrote:
>
> On 2017/12/15 23:50, James Morse wrote:
>> +asmlinkage void do_serror(struct pt_regs *regs, unsigned int esr)
>> +{
>> + nmi_enter();
>
> How about firstly let APEI kernel driver to handle it by adding patch[1]? if the handling is successful, do_serror() direct return;
> Otherwise continue check the ESR value, for example:
> if (!ghes_notify_sei())
> return;
This is where I think we will end up. Adding that could should be part of a
future firmware-first series.
We can't do it until APEI can share its in_nmi() path with multiple users. (what
happens if we take an SError while handling an NOTIFY_SEA).
I still haven't managed to get the RFC of what I think is required out.
(I need this for SDEI too),
>> +
>> + /* non-RAS errors are not containable */
>> + if (!arm64_is_ras_serror(esr) || arm64_is_fatal_ras_serror(regs, esr))
>> + arm64_serror_panic(regs, esr);
>>
>> - panic("Asynchronous SError Interrupt");
>> + nmi_exit();
>> }
Thanks,
James
^ permalink raw reply
* [PATCH v5 04/13] arm64: kernel: Survive corrected RAS errors notified by SError
From: James Morse @ 2018-01-05 18:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <720fa5cc-93a9-8844-c2f3-83116a724d1b@huawei.com>
Hi gengdongjiu,
On 16/12/17 04:51, gengdongjiu wrote:
> On 2017/12/16 12:08, gengdongjiu wrote:
>> On 2017/12/15 23:50, James Morse wrote:
>>> + case ESR_ELx_AET_UER: /* Uncorrected Recoverable */
>>> + /*
>>> + * The CPU can't make progress. The exception may have
>>> + * been imprecise.
>>> + */
>>> + return true;
>> For Recoverable error (UER), the error has not been silently propagated,
>> and has not been architecturally consumed by the PE, and
>> The exception is precise and PE can recover execution from the preferred return address of the exception.
>> so I do not think it should be panic here if the SError come from user space instead of coming from kernel space.
'coming from' doesn't mean an awful lot unless we know what the error is.
To repeat the earlier examples, it could be a fault in the page tables, or pages
shared between processes, e.g. the vdso data page.
I don't want this crude panic/continue to consider anything other than the ESR.
Lets keep it crude, its a stop-gap: both kernel-first and firmware-first can do
a better job - this is just some glue to hold things together until we have
one/both implemented.
[...]
> Recoverable error (UER)
> The state of the PE is Recoverable if all of the following are true:
> ? The error has not been silently propagated.
> ? The error has not been architecturally consumed by the PE. (The PE architectural state is not infected.)
> ? The exception is precise and PE can recover execution from the preferred return address of the exception, if software locates and repairs the error.
It's this bit that made me err on the side of caution/panic():
> The PE cannot make correct progress without either consuming the error or
> otherwise making the error unrecoverable. The error remains latent in the system.
Without firmware-first or kernel-first we can't know where the error is. What
should we do?:
> If software cannot locate and repair the error, either the application or the
> VM, or both, must be isolated by software.
Thanks,
James
^ permalink raw reply
* [PATCH v7 07/10] kernel/jump_label: abstract jump_entry member accessors
From: Ard Biesheuvel @ 2018-01-05 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105182229.pjnlq3l5hzfac4na@armageddon.cambridge.arm.com>
On 5 January 2018 at 18:22, Catalin Marinas <catalin.marinas@arm.com> wrote:
> On Fri, Jan 05, 2018 at 06:01:33PM +0000, Ard Biesheuvel wrote:
>> On 5 January 2018 at 17:58, Catalin Marinas <catalin.marinas@arm.com> wrote:
>> > On Tue, Jan 02, 2018 at 08:05:46PM +0000, Ard Biesheuvel wrote:
>> >> diff --git a/arch/arm/include/asm/jump_label.h b/arch/arm/include/asm/jump_label.h
>> >> index e12d7d096fc0..7b05b404063a 100644
>> >> --- a/arch/arm/include/asm/jump_label.h
>> >> +++ b/arch/arm/include/asm/jump_label.h
>> >> @@ -45,5 +45,32 @@ struct jump_entry {
>> >> jump_label_t key;
>> >> };
>> >>
>> >> +static inline jump_label_t jump_entry_code(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code;
>> >> +}
>> >> +
>> >> +static inline struct static_key *jump_entry_key(const struct jump_entry *entry)
>> >> +{
>> >> + return (struct static_key *)((unsigned long)entry->key & ~1UL);
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_branch(const struct jump_entry *entry)
>> >> +{
>> >> + return (unsigned long)entry->key & 1UL;
>> >> +}
>> >> +
>> >> +static inline bool jump_entry_is_module_init(const struct jump_entry *entry)
>> >> +{
>> >> + return entry->code == 0;
>> >> +}
>> >> +
>> >> +static inline void jump_entry_set_module_init(struct jump_entry *entry)
>> >> +{
>> >> + entry->code = 0;
>> >> +}
>> >> +
>> >> +#define jump_label_swap NULL
>> >
>> > Is there any difference between these functions on any of the
>> > architectures touched? Even with the relative offset, arm64 and x86
>> > looked the same to me (well, I may have missed some detail).
>>
>> No, the latter two are identical everywhere, and the others are the
>> same modulo absolute vs relative.
>>
>> The issue is that the struct definition is per-arch so the accessors
>> should be as well.
>
> Up to this patch, even the jump_entry structure is the same on all
> architectures (the jump_label_t type differs).
>
> With relative offset, can you not just define jump_label_t to s32? At a
> quick grep in mainline, it doesn't seem to be used outside the structure
> definition.
>
I think we can just remove jump_label_t entirely, and replace it with
unsigned long for absolute, and s32 for relative. Maybe I am missing
something, but things like
#ifdef CONFIG_X86_64
typedef u64 jump_label_t;
#else
typedef u32 jump_label_t;
#endif
seem a bit pointless to me anyway.
>> Perhaps I should introduce two variants two asm-generic, similar to
>> how we have different flavors of unaligned accessors.
>
> You could as well define them directly in kernel/jump_label.h or, if
> used outside this file, include/linux/jump_label.h.
>
Perhaps I should define a Kconfig symbol after all for relative jump
labels, and just keep everything in the same file. The question is
whether I should use CONFIG_HAVE_ARCH_PREL32_RELOCATIONS for this as
well.
^ permalink raw reply
* [v2 PATCH 5/6] dt-bindings: usb: mtk-xhci: update USB wakeup properties
From: Rob Herring @ 2018-01-05 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7c7f69a3981b5117f7c8cc14b19c3459a50403ef.1514967463.git.chunfeng.yun@mediatek.com>
On Wed, Jan 03, 2018 at 04:53:21PM +0800, Chunfeng Yun wrote:
> Add two arguments in "mediatek,syscon-wakeup" to support multi
> wakeup glue layer between SSUSB and SPM, and use standard property
> "wakeup-source" to replace the private "mediatek,wakeup-src"
>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> .../devicetree/bindings/usb/mediatek,mtk-xhci.txt | 16 ++++++++++------
> 1 file changed, 10 insertions(+), 6 deletions(-)
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [GIT PULL 1/3] ARM: Keystone DTS for 4.16
From: santosh.shilimkar at oracle.com @ 2018-01-05 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180105071233.dlgob4hufvstuwi4@localhost>
On 1/4/18 11:12 PM, Olof Johansson wrote:
> On Wed, Dec 27, 2017 at 06:07:50PM -0800, Santosh Shilimkar wrote:
>> The following changes since commit 4fbd8d194f06c8a3fd2af1ce560ddb31f7ec8323:
>>
>> Linux 4.15-rc1 (2017-11-26 16:01:47 -0800)
>>
>> are available in the git repository at:
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git tags/keystone_dts_for_4.16
>>
>> for you to fetch changes up to 4fe85b0cdd06f8fef2631923799bdc95380badb5:
>>
>> ARM: dts: keystone-k2l-clocks: Add missing unit name to clock nodes that have regs (2017-12-16 14:36:57 -0800)
>>
>> ----------------------------------------------------------------
>> ARM: Keystone DTS update for 4.16
>>
>> - Enable GPIO bank2 for K2L
>> - Enable QSPI for K2G & K2G-EVM
>> - Enable UART1/2 for K2G & K2G-EVM
>> - Enable peripherals for K2G-ICE
>> - Fix C1 and C2 DTS warnings
>
> Merged, thanks.
>
Thanks !!
^ permalink raw reply
* [PATCH v2 1/7] drm/panel: simple: add support for Ampire AM-800480AYTZQW-00H
From: Rob Herring @ 2018-01-05 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-2-git-send-email-jagan@amarulasolutions.com>
On Thu, Jan 04, 2018 at 11:42:19AM +0530, Jagan Teki wrote:
> This adds support for the Ampire AM-800480AYTZQW-00H 7.0" WGA LCD,
> which can be supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Updated binding info about optional properties, node and example
>
> .../display/panel/ampire,am-800480aytzqw-00h.txt | 25 ++++++++++++++++++++
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ampire,am-800480aytzqw-00h.txt
^ permalink raw reply
* [PATCH v2 4/7] drm/panel: simple: Add support for KEO TX31D200VM0BAA
From: Rob Herring @ 2018-01-05 18:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1515046345-15881-5-git-send-email-jagan@amarulasolutions.com>
On Thu, Jan 04, 2018 at 11:42:22AM +0530, Jagan Teki wrote:
> This adds support for the Kaohsiung Opto-Electronics.,
> TX31D200VM0BAA 12.3" HSXGA LVDS panel, which can be
> supported by the simple panel driver.
>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v2:
> - Updated binding info about optional properties, node and example
>
> .../bindings/display/panel/koe,tx31d200vm0baa.txt | 25 ++++++++++++++++++++
Reviewed-by: Rob Herring <robh@kernel.org>
> drivers/gpu/drm/panel/panel-simple.c | 27 ++++++++++++++++++++++
> 2 files changed, 52 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/koe,tx31d200vm0baa.txt
^ permalink raw reply
* [PATCH v1 4/6] dt-bindings: clock: mediatek: add "simple-mfd" in audsys documentation
From: Rob Herring @ 2018-01-05 19:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bd1cb0aeaf07b4bf2cedbf00ef8fedc6ba01f9cb.1515038387.git.ryder.lee@mediatek.com>
On Thu, Jan 04, 2018 at 03:44:20PM +0800, Ryder Lee wrote:
> Add "simple-mfd" to support MFD device and add a compatible string for MT2701.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> .../bindings/arm/mediatek/mediatek,audsys.txt | 21 +++++++++++++++------
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> index 9b8f578..6e97552 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,audsys.txt
> @@ -6,17 +6,25 @@ The MediaTek AUDSYS controller provides various clocks to the system.
> Required Properties:
>
> - compatible: Should be one of:
> - - "mediatek,mt7622-audsys", "syscon"
> + - "mediatek,mt2701-audsys", "syscon", "simple-mfd"
> + - "mediatek,mt7622-audsys", "syscon", "simple-mfd"
> - #clock-cells: Must be 1
I don't think this is a simple-mfd. The AFE uses clocks created by its
parent, right? So the parent should be probed first. You should have
the parent instantiate the child nodes.
> The AUDSYS controller uses the common clk binding from
> Documentation/devicetree/bindings/clock/clock-bindings.txt
> The available clocks are defined in dt-bindings/clock/mt*-clk.h.
>
> +See ../sound/mt2701-afe-pcm.txt for details about required subnode.
> +
> Example:
>
> -audsys: audsys at 11220000 {
> - compatible = "mediatek,mt7622-audsys", "syscon";
> - reg = <0 0x11220000 0 0x1000>;
> - #clock-cells = <1>;
> -};
> + audsys: audio-subsystem at 11220000 {
> + compatible = "mediatek,mt2701-audsys", "syscon", "simple-mfd";
> + reg = <0 0x11220000 0 0x1000>;
> + #clock-cells = <1>;
> +
> + afe: audio-controller {
> + compatible = "mediatek,mt2701-audio";
> + ...
> + };
> + };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v1 5/6] clk: mediatek: update missing clock data for MT7622 audsys
From: Rob Herring @ 2018-01-05 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <296e97ad8720d575918657e821bb2a01a2d31c49.1515038387.git.ryder.lee@mediatek.com>
On Thu, Jan 04, 2018 at 03:44:21PM +0800, Ryder Lee wrote:
> Add missing clock data 'CLK_AUDIO_AFE_CONN' for MT7622 audsys.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> drivers/clk/mediatek/clk-mt7622-aud.c | 3 ++-
> include/dt-bindings/clock/mt7622-clk.h | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt7622-aud.c b/drivers/clk/mediatek/clk-mt7622-aud.c
> index fad7d9f..96959ad 100644
> --- a/drivers/clk/mediatek/clk-mt7622-aud.c
> +++ b/drivers/clk/mediatek/clk-mt7622-aud.c
> @@ -106,6 +106,7 @@
> GATE_AUDIO1(CLK_AUDIO_INTDIR, "audio_intdir", "intdir_sel", 20),
> GATE_AUDIO1(CLK_AUDIO_A1SYS, "audio_a1sys", "a1sys_hp_sel", 21),
> GATE_AUDIO1(CLK_AUDIO_A2SYS, "audio_a2sys", "a2sys_hp_sel", 22),
> + GATE_AUDIO1(CLK_AUDIO_AFE_CONN, "audio_afe_conn", "a1sys_hp_sel", 23),
> /* AUDIO2 */
> GATE_AUDIO2(CLK_AUDIO_UL1, "audio_ul1", "a1sys_hp_sel", 0),
> GATE_AUDIO2(CLK_AUDIO_UL2, "audio_ul2", "a1sys_hp_sel", 1),
> @@ -146,7 +147,7 @@ static int clk_mt7622_audiosys_init(struct platform_device *pdev)
> clk_data = mtk_alloc_clk_data(CLK_AUDIO_NR_CLK);
>
> mtk_clk_register_gates(node, audio_clks, ARRAY_SIZE(audio_clks),
> - clk_data);
> + clk_data);
Drop this unrelated change.
>
> r = of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
> if (r)
> diff --git a/include/dt-bindings/clock/mt7622-clk.h b/include/dt-bindings/clock/mt7622-clk.h
> index 3e514ed..e9d77f0 100644
> --- a/include/dt-bindings/clock/mt7622-clk.h
> +++ b/include/dt-bindings/clock/mt7622-clk.h
> @@ -235,7 +235,8 @@
> #define CLK_AUDIO_MEM_ASRC3 43
> #define CLK_AUDIO_MEM_ASRC4 44
> #define CLK_AUDIO_MEM_ASRC5 45
> -#define CLK_AUDIO_NR_CLK 46
> +#define CLK_AUDIO_AFE_CONN 46
> +#define CLK_AUDIO_NR_CLK 47
>
> /* SSUSBSYS */
>
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/5] clk: lpc32xx: read-only divider can propagate rate change
From: Jerome Brunet @ 2018-01-05 19:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5a256cde-8e59-4921-f6e2-fecd3d1c3377@mleia.com>
On Fri, 2018-01-05 at 20:12 +0200, Vladimir Zapolskiy wrote:
> Hi Jerome,
>
> On 01/05/2018 07:09 PM, Jerome Brunet wrote:
> > When a divider clock has CLK_DIVIDER_READ_ONLY set, it means that the
> > register shall be left un-touched, but it does not mean the clock
> > should stop rate propagation if CLK_SET_RATE_PARENT is set
> >
>
> okay, the statement sounds correct, but there is no such clocks on LPC32xx,
> thus I hardly can confirm that adding dead/inapplicable code is a fix.
>
> > This properly handled in qcom clk-regmap-divider but it was not in the
> > lpc32xx divider
> >
> > Fixes: f7c82a60ba26 ("clk: lpc32xx: add common clock framework driver")
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>
> I would suggest to drop two LPC32xx clock driver changes from the series.
Hi Vladimir,
This is fine by me. Whether LPC32xx supports CLK_DIVIDER_READ_ONLY is up to you,
but you should be consistent about it.
I added the fix to LPC32xx because it looks like the generic divider (a lot) and
appears to support CLK_DIVIDER_READ_ONLY. If it does not, could you please kill
the related code ?
Regards
Jerome
>
> --
> With best wishes,
> Vladimir
^ permalink raw reply
* [PATCH 09/67] arc: remove CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
From: Vineet Gupta @ 2018-01-05 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171229081911.2802-10-hch@lst.de>
On 12/29/2017 12:25 AM, Christoph Hellwig wrote:
> We always use the stub definitions, so remove the unused other code.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Vineet Gupta <vgupta@synopsys.com>
FWIW, it was removed and reintroduced as one of the customers wanted it, which is
not relevant now !
Thx,
-Vineet
> ---
> arch/arc/Kconfig | 3 ---
> arch/arc/include/asm/dma-mapping.h | 7 -------
> arch/arc/mm/dma.c | 14 +++++++-------
> 3 files changed, 7 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
> index 9d5fd00d9e91..f3a80cf164cc 100644
> --- a/arch/arc/Kconfig
> +++ b/arch/arc/Kconfig
> @@ -463,9 +463,6 @@ config ARCH_PHYS_ADDR_T_64BIT
> config ARCH_DMA_ADDR_T_64BIT
> bool
>
> -config ARC_PLAT_NEEDS_PHYS_TO_DMA
> - bool
> -
> config ARC_KVADDR_SIZE
> int "Kernel Virtual Address Space size (MB)"
> range 0 512
> diff --git a/arch/arc/include/asm/dma-mapping.h b/arch/arc/include/asm/dma-mapping.h
> index 94285031c4fb..7a16824bfe98 100644
> --- a/arch/arc/include/asm/dma-mapping.h
> +++ b/arch/arc/include/asm/dma-mapping.h
> @@ -11,13 +11,6 @@
> #ifndef ASM_ARC_DMA_MAPPING_H
> #define ASM_ARC_DMA_MAPPING_H
>
> -#ifndef CONFIG_ARC_PLAT_NEEDS_PHYS_TO_DMA
> -#define plat_dma_to_phys(dev, dma_handle) ((phys_addr_t)(dma_handle))
> -#define plat_phys_to_dma(dev, paddr) ((dma_addr_t)(paddr))
> -#else
> -#include <plat/dma.h>
> -#endif
> -
> extern const struct dma_map_ops arc_dma_ops;
>
> static inline const struct dma_map_ops *get_arch_dma_ops(struct bus_type *bus)
> diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
> index fad18261ef6a..1d405b86250c 100644
> --- a/arch/arc/mm/dma.c
> +++ b/arch/arc/mm/dma.c
> @@ -60,7 +60,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> /* This is linear addr (0x8000_0000 based) */
> paddr = page_to_phys(page);
>
> - *dma_handle = plat_phys_to_dma(dev, paddr);
> + *dma_handle = paddr;
>
> /* This is kernel Virtual address (0x7000_0000 based) */
> if (need_kvaddr) {
> @@ -92,7 +92,7 @@ static void *arc_dma_alloc(struct device *dev, size_t size,
> static void arc_dma_free(struct device *dev, size_t size, void *vaddr,
> dma_addr_t dma_handle, unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, dma_handle);
> + phys_addr_t paddr = dma_handle;
> struct page *page = virt_to_page(paddr);
> int is_non_coh = 1;
>
> @@ -111,7 +111,7 @@ static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
> {
> unsigned long user_count = vma_pages(vma);
> unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
> - unsigned long pfn = __phys_to_pfn(plat_dma_to_phys(dev, dma_addr));
> + unsigned long pfn = __phys_to_pfn(dma_addr);
> unsigned long off = vma->vm_pgoff;
> int ret = -ENXIO;
>
> @@ -175,7 +175,7 @@ static dma_addr_t arc_dma_map_page(struct device *dev, struct page *page,
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
>
> - return plat_phys_to_dma(dev, paddr);
> + return paddr;
> }
>
> /*
> @@ -190,7 +190,7 @@ static void arc_dma_unmap_page(struct device *dev, dma_addr_t handle,
> size_t size, enum dma_data_direction dir,
> unsigned long attrs)
> {
> - phys_addr_t paddr = plat_dma_to_phys(dev, handle);
> + phys_addr_t paddr = handle;
>
> if (!(attrs & DMA_ATTR_SKIP_CPU_SYNC))
> _dma_cache_sync(paddr, size, dir);
> @@ -224,13 +224,13 @@ static void arc_dma_unmap_sg(struct device *dev, struct scatterlist *sg,
> static void arc_dma_sync_single_for_cpu(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_FROM_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_FROM_DEVICE);
> }
>
> static void arc_dma_sync_single_for_device(struct device *dev,
> dma_addr_t dma_handle, size_t size, enum dma_data_direction dir)
> {
> - _dma_cache_sync(plat_dma_to_phys(dev, dma_handle), size, DMA_TO_DEVICE);
> + _dma_cache_sync(dma_handle, size, DMA_TO_DEVICE);
> }
>
> static void arc_dma_sync_sg_for_cpu(struct device *dev,
^ permalink raw reply
* [Bug] Endless deferred probe of dwc2 on RPi 3
From: Stefan Wahren @ 2018-01-05 20:11 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
i noticed on my Raspberry Pi 3 (Linux 4.15rc6, ARM64, defconfig) that probing of dwc2 driver is deferred endlessly. This issue is triggered by a recent DT clean up 014d6da6cb25 ("ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells") which is correct according to Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
Here is the call stack which always returns -EPROBE_DEFER on this platform:
dwc2_lowlevel_hw_init()
devm_phy_get()
phy_get()
_of_phy_get()
Btw Raspberry Pi 2 (ARM, multi_v7_defconfig) is also affected, but not Raspberry Pi Zero W (ARM, bcm2835_config) while all 3 platforms share the same USB DT nodes.
Any ideas to fix this issue are welcome.
Best regards
Stefan
^ permalink raw reply
* [PATCH] arm64: Implement branch predictor hardening for Falkor
From: Shanker Donthineni @ 2018-01-05 20:28 UTC (permalink / raw)
To: linux-arm-kernel
Falkor is susceptible to branch predictor aliasing and can
theoretically be attacked by malicious code. This patch
implements a mitigation for these attacks, preventing any
malicious entries from affecting other victim contexts.
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
---
This patch has been verified using tip of
https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=kpti
and
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm64?h=v4.15-rc6&id=c622cc013cece073722592cff1ac6643a33b1622
arch/arm64/include/asm/cpucaps.h | 3 ++-
arch/arm64/include/asm/kvm_asm.h | 2 ++
arch/arm64/kernel/bpi.S | 8 +++++++
arch/arm64/kernel/cpu_errata.c | 49 ++++++++++++++++++++++++++++++++++++++--
arch/arm64/kvm/hyp/entry.S | 12 ++++++++++
arch/arm64/kvm/hyp/switch.c | 10 ++++++++
6 files changed, 81 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/cpucaps.h b/arch/arm64/include/asm/cpucaps.h
index 51616e7..7049b48 100644
--- a/arch/arm64/include/asm/cpucaps.h
+++ b/arch/arm64/include/asm/cpucaps.h
@@ -43,7 +43,8 @@
#define ARM64_SVE 22
#define ARM64_UNMAP_KERNEL_AT_EL0 23
#define ARM64_HARDEN_BRANCH_PREDICTOR 24
+#define ARM64_HARDEN_BP_POST_GUEST_EXIT 25
-#define ARM64_NCAPS 25
+#define ARM64_NCAPS 26
#endif /* __ASM_CPUCAPS_H */
diff --git a/arch/arm64/include/asm/kvm_asm.h b/arch/arm64/include/asm/kvm_asm.h
index ab4d0a9..24961b7 100644
--- a/arch/arm64/include/asm/kvm_asm.h
+++ b/arch/arm64/include/asm/kvm_asm.h
@@ -68,6 +68,8 @@
extern u32 __init_stage2_translation(void);
+extern void __qcom_hyp_sanitize_btac_predictors(void);
+
#endif
#endif /* __ARM_KVM_ASM_H__ */
diff --git a/arch/arm64/kernel/bpi.S b/arch/arm64/kernel/bpi.S
index 2b10d52..44ffcda 100644
--- a/arch/arm64/kernel/bpi.S
+++ b/arch/arm64/kernel/bpi.S
@@ -77,3 +77,11 @@ ENTRY(__psci_hyp_bp_inval_start)
ldp x2, x3, [sp], #16
ldp x0, x1, [sp], #16
ENTRY(__psci_hyp_bp_inval_end)
+
+ENTRY(__qcom_hyp_sanitize_link_stack_start)
+ stp x29, x30, [sp, #-16]!
+ .rept 16
+ bl . + 4
+ .endr
+ ldp x29, x30, [sp], #16
+ENTRY(__qcom_hyp_sanitize_link_stack_end)
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index cb0fb37..daf53a5 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -54,6 +54,8 @@ static int cpu_enable_trap_ctr_access(void *__unused)
#ifdef CONFIG_KVM
extern char __psci_hyp_bp_inval_start[], __psci_hyp_bp_inval_end[];
+extern char __qcom_hyp_sanitize_link_stack_start[];
+extern char __qcom_hyp_sanitize_link_stack_end[];
static void __copy_hyp_vect_bpi(int slot, const char *hyp_vecs_start,
const char *hyp_vecs_end)
@@ -96,8 +98,10 @@ static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
spin_unlock(&bp_lock);
}
#else
-#define __psci_hyp_bp_inval_start NULL
-#define __psci_hyp_bp_inval_end NULL
+#define __psci_hyp_bp_inval_start NULL
+#define __psci_hyp_bp_inval_end NULL
+#define __qcom_hyp_sanitize_link_stack_start NULL
+#define __qcom_hyp_sanitize_link_stack_start NULL
static void __install_bp_hardening_cb(bp_hardening_cb_t fn,
const char *hyp_vecs_start,
@@ -138,6 +142,29 @@ static int enable_psci_bp_hardening(void *data)
return 0;
}
+
+static void qcom_link_stack_sanitization(void)
+{
+ u64 tmp;
+
+ asm volatile("mov %0, x30 \n"
+ ".rept 16 \n"
+ "bl . + 4 \n"
+ ".endr \n"
+ "mov x30, %0 \n"
+ : "=&r" (tmp));
+}
+
+static int qcom_enable_link_stack_sanitization(void *data)
+{
+ const struct arm64_cpu_capabilities *entry = data;
+
+ install_bp_hardening_cb(entry, qcom_link_stack_sanitization,
+ __qcom_hyp_sanitize_link_stack_start,
+ __qcom_hyp_sanitize_link_stack_end);
+
+ return 0;
+}
#endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
#define MIDR_RANGE(model, min, max) \
@@ -302,6 +329,24 @@ static int enable_psci_bp_hardening(void *data)
MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
.enable = enable_psci_bp_hardening,
},
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
+ .enable = qcom_enable_link_stack_sanitization,
+ },
+ {
+ .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
+ .enable = qcom_enable_link_stack_sanitization,
+ },
+ {
+ .capability = ARM64_HARDEN_BP_POST_GUEST_EXIT,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR_V1),
+ },
+ {
+ .capability = ARM64_HARDEN_BP_POST_GUEST_EXIT,
+ MIDR_ALL_VERSIONS(MIDR_QCOM_FALKOR),
+ },
#endif
{
}
diff --git a/arch/arm64/kvm/hyp/entry.S b/arch/arm64/kvm/hyp/entry.S
index 12ee62d..9c45c6a 100644
--- a/arch/arm64/kvm/hyp/entry.S
+++ b/arch/arm64/kvm/hyp/entry.S
@@ -196,3 +196,15 @@ alternative_endif
eret
ENDPROC(__fpsimd_guest_restore)
+
+ENTRY(__qcom_hyp_sanitize_btac_predictors)
+ /**
+ * Call SMC64 with Silicon provider serviceID 23<<8 (0xc2001700)
+ * 0xC2000000-0xC200FFFF: assigned to SiP Service Calls
+ * b15-b0: contains SiP functionID
+ */
+ movz x0, #0x1700
+ movk x0, #0xc200, lsl #16
+ smc #0
+ ret
+ENDPROC(__qcom_hyp_sanitize_btac_predictors)
diff --git a/arch/arm64/kvm/hyp/switch.c b/arch/arm64/kvm/hyp/switch.c
index 4d273f6..7e37379 100644
--- a/arch/arm64/kvm/hyp/switch.c
+++ b/arch/arm64/kvm/hyp/switch.c
@@ -406,6 +406,16 @@ int __hyp_text __kvm_vcpu_run(struct kvm_vcpu *vcpu)
/* 0 falls through to be handled out of EL2 */
}
+ if (cpus_have_const_cap(ARM64_HARDEN_BP_POST_GUEST_EXIT)) {
+ u32 midr = read_cpuid_id();
+
+ /* Apply BTAC predictors mitigation to all Falkor chips */
+ if (((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR) ||
+ ((midr & MIDR_CPU_MODEL_MASK) == MIDR_QCOM_FALKOR_V1)) {
+ __qcom_hyp_sanitize_btac_predictors();
+ }
+ }
+
fp_enabled = __fpsimd_enabled();
__sysreg_save_guest_state(guest_ctxt);
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] mtd/nand/atmel: Delete an error message for a failed memory allocation in two functions
From: SF Markus Elfring @ 2018-01-05 20:55 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 5 Jan 2018 21:45:04 +0100
Omit an extra message for a memory allocation failure in these functions.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/mtd/nand/atmel/nand-controller.c | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/mtd/nand/atmel/nand-controller.c b/drivers/mtd/nand/atmel/nand-controller.c
index 90a71a56bc23..a41b999229c9 100644
--- a/drivers/mtd/nand/atmel/nand-controller.c
+++ b/drivers/mtd/nand/atmel/nand-controller.c
@@ -1612,10 +1612,8 @@ static int atmel_nand_register(struct atmel_nand *nand)
mtd->name = devm_kasprintf(nc->dev, GFP_KERNEL,
"%s:nand.%d", dev_name(nc->dev),
nand->cs[0].id);
- if (!mtd->name) {
- dev_err(nc->dev, "Failed to allocate mtd->name\n");
+ if (!mtd->name)
return -ENOMEM;
- }
}
ret = nand_scan_tail(mtd);
@@ -1654,10 +1652,8 @@ static struct atmel_nand *atmel_nand_create(struct atmel_nand_controller *nc,
nand = devm_kzalloc(nc->dev,
sizeof(*nand) + (numcs * sizeof(*nand->cs)),
GFP_KERNEL);
- if (!nand) {
- dev_err(nc->dev, "Failed to allocate NAND object\n");
+ if (!nand)
return ERR_PTR(-ENOMEM);
- }
nand->numcs = numcs;
--
2.15.1
^ permalink raw reply related
* [PATCH] mtd/nand/sunxi: Delete an error message for a failed memory allocation in sunxi_nand_chip_init()
From: SF Markus Elfring @ 2018-01-05 21:34 UTC (permalink / raw)
To: linux-arm-kernel
From: Markus Elfring <elfring@users.sourceforge.net>
Date: Fri, 5 Jan 2018 22:27:09 +0100
Omit an extra message for a memory allocation failure in this function.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
---
drivers/mtd/nand/sunxi_nand.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 82244be3e766..ebfa130a9285 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -2019,10 +2019,8 @@ static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
sizeof(*chip) +
(nsels * sizeof(struct sunxi_nand_chip_sel)),
GFP_KERNEL);
- if (!chip) {
- dev_err(dev, "could not allocate chip\n");
+ if (!chip)
return -ENOMEM;
- }
chip->nsels = nsels;
chip->selected = -1;
--
2.15.1
^ 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